https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82731
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-15
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108602
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580
Alexandre Oliva changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82731
--- Comment #2 from Andrew Pinski ---
Note you can reproduce the same issue with SSE2 (and not just AVX):
```
#define vect16 __attribute__((vector_size(16)))
vect16 char gather(char *array, unsigned short *offset) {
return (vect16 char){arra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85223
Andrew Pinski changed:
What|Removed |Added
Keywords||internal-improvement
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92880
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #19 from Hu Lin ---
(In reply to Jakub Jelinek from comment #18)
> (In reply to Hu Lin from comment #17)
> > (In reply to Jakub Jelinek from comment #16)
> > >
> > > No, -ftrapv isn't a debugging tool. There is no overflow in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #9 from kugan at gcc dot gnu.org ---
Looking at the options, looks to me that making loop->safelen a poly_in is the
way to go. (In reply to Jakub Jelinek from comment #4)
> The OpenMP safelen clause argument is a scalar integer, so us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #10 from kugan at gcc dot gnu.org ---
Created attachment 57946
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57946&action=edit
patch
patch to make loop->safelen a poly_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #11 from Jakub Jelinek ---
(In reply to kugan from comment #9)
> Looking at the options, looks to me that making loop->safelen a poly_in is
> the way to go. (In reply to Jakub Jelinek from comment #4)
> > The OpenMP safelen clause ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114703
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #12 from kugan at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to kugan from comment #9)
> > Looking at the options, looks to me that making loop->safelen a poly_in is
> > the way to go. (In reply to Ja
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114704
--- Comment #5 from Richard Biener ---
We're not handling "phi translation" in the lookup phase when determining if
there's a redundant store (PHI translation for the virtual operand). In
particular value-numbering never considers whether an ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #13 from Jakub Jelinek ---
(In reply to kugan from comment #12)
> > Why?
> > Then it just is INT_MAX value, which is a magic value that says that it is
> > infinity.
> > No need to say it is a poly_int infinity.
>
> For this test ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #14 from Richard Biener ---
I think
if (safelen)
{
poly_uint64 val;
safelen = OMP_CLAUSE_SAFELEN_EXPR (safelen);
if (!poly_int_tree_p (safelen, &val))
safelen_int = 0;
else
safelen_int =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114717
Bug ID: 114717
Summary: '-fcf-protection' vs. offloading compilation
Product: gcc
Version: 14.0
URL: https://github.com/gcc-mirror/gcc/commit/1bf18629c54ad
f4893c8db5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #15 from rguenther at suse dot de ---
On Mon, 15 Apr 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
>
> --- Comment #13 from Jakub Jelinek ---
> (In reply to kugan from comment #12)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #16 from Jakub Jelinek ---
(In reply to Richard Biener from comment #14)
> I think
>
> if (safelen)
> {
> poly_uint64 val;
> safelen = OMP_CLAUSE_SAFELEN_EXPR (safelen);
> if (!poly_int_tree_p (safelen, &val)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114711
--- Comment #4 from Richard Biener ---
This one requires "symbolicizing" an initializer. That might for example also
help implementing a non-constant initializer with a loop, reducing .data and
possibly relocations. It might also help reducing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114718
Bug ID: 114718
Summary: GCN's '-march'es vs. default multilib
Product: gcc
Version: 14.0
URL: https://github.com/gcc-mirror/gcc/commit/1bf18629c54ad
f4893c8db5227a36e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #17 from rguenther at suse dot de ---
On Mon, 15 Apr 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
>
> --- Comment #16 from Jakub Jelinek ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114718
Andrew Pinski changed:
What|Removed |Added
URL|https://github.com/gcc-mirr |
|or/gcc/commit/1bf18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114718
Andrew Pinski changed:
What|Removed |Added
Component|target |driver
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114713
Richard Biener changed:
What|Removed |Added
Version|unknown |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #11 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:3878e9aeb30cb192f769997c52743daf8190744c
commit r14-9961-g3878e9aeb30cb192f769997c52743daf8190744c
Author: Nathaniel Shead
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114717
Andrew Pinski changed:
What|Removed |Added
URL|https://github.com/gcc-mirr |
|or/gcc/commit/1bf18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114718
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-15
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114713
--- Comment #2 from Richard Biener ---
Also note that people might find it reasonable to access
struct { int n; int a[4]; } a = { 4, };
via
struct X { int n; int a[] } *p;
The fortran frontend goes some lengths to make this work for array
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114719
Bug ID: 114719
Summary: Missed optimization: conditional in loop is an
invariant (a%2)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114720
Bug ID: 114720
Summary: gcc.misc-tests/gcov-22.c loops
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114715
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-04-15
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114715
--- Comment #2 from Richard Biener ---
Besides OMP the switch gimplification code is the only one building a new BIND.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114715
--- Comment #3 from Richard Biener ---
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 3df58b962f3..26e96ada4c7 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -3017,6 +3017,7 @@ gimplify_switch_expr (tree *expr_p, gimple_seq *pre_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #18 from kugan at gcc dot gnu.org ---
Also, can we set INT_MAX when there is no explicit safelen specified in OMP.
Something like:
--- a/gcc/omp-low.cc
+++ b/gcc/omp-low.cc
@@ -6975,14 +6975,11 @@ lower_rec_input_clauses (tree clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114715
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114703
--- Comment #3 from Jan Hubicka ---
> Yep, 'new' memory escapes.
Yep, this is blocking a lot of propagation in common C++ code.
Here it may help to do speculative devirtualization during IPA stage
that will let the late optimization to get rid o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
--- Comment #2 from Li Pan ---
The vzext.vf2 has earlyclobber dest operand, and then it cannot allocated to
the source operand, like vzext.vf2 v0, v0. Thus we will fail when check_rtl.
(define_insn "@pred__vf2"
[(set (match_operand:VWEXTI 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #28 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:85002f8085c25bb3e74ab013581a74e7c7ae006b
commit r14-9969-g85002f8085c25bb3e74ab013581a74e7c7ae006b
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113552
--- Comment #13 from GCC Commits ---
The releases/gcc-13 branch has been updated by Tamar Christina
:
https://gcc.gnu.org/g:1e08e39c743692afdd5d3546b2223474beac1dbc
commit r13-8604-g1e08e39c743692afdd5d3546b2223474beac1dbc
Author: Tamar Christ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114686
--- Comment #3 from Robin Dapp ---
I think we have always maintained that this can definitely be a per-uarch
default but shouldn't be a generic default.
> I don't see any reason why this wouldn't be the case for the vast majority of
> implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114696
--- Comment #4 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:a3281dd0f4b46c16ec1192ad411c0a96e6d086eb
commit r14-9970-ga3281dd0f4b46c16ec1192ad411c0a96e6d086eb
Author: H.J. Lu
Date: Fri Apr 12 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
--- Comment #18 from GCC Commits ---
The releases/gcc-13 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:abe3a80aa2d6d53cc9b8c9f7c531e065451d5b6e
commit r13-8606-gabe3a80aa2d6d53cc9b8c9f7c531e065451d5b6e
Author: H.J. Lu
Date: Sun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
--- Comment #19 from GCC Commits ---
The releases/gcc-12 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:23049e851ebf840dffdd3f062dba0e795be347f8
commit r12-10331-g23049e851ebf840dffdd3f062dba0e795be347f8
Author: H.J. Lu
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
--- Comment #20 from GCC Commits ---
The releases/gcc-11 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:574d52a9b6e40a466b90f4810e72d3dd072d5160
commit r11-11321-g574d52a9b6e40a466b90f4810e72d3dd072d5160
Author: H.J. Lu
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114696
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113552
--- Comment #14 from GCC Commits ---
The releases/gcc-11 branch has been updated by Tamar Christina
:
https://gcc.gnu.org/g:0c2fcf3ddfe93d1f403962c4bacbb5d55ab7d19d
commit r11-11323-g0c2fcf3ddfe93d1f403962c4bacbb5d55ab7d19d
Author: Tamar Chris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113552
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114715
Richard Biener changed:
What|Removed |Added
Known to work||14.0
--- Comment #4 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114719
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114717
Richard Biener changed:
What|Removed |Added
Keywords||lto
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114717
--- Comment #3 from Andrew Stubbs ---
Can this be filtered (safely) in mkoffload? That tool is
offload-target-specific, so no problem with "if offload target were to support
it".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114717
--- Comment #4 from Richard Biener ---
(In reply to Andrew Stubbs from comment #3)
> Can this be filtered (safely) in mkoffload? That tool is
> offload-target-specific, so no problem with "if offload target were to
> support it".
Yes, I think s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114668
--- Comment #3 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:02cc8f3e68f9af96d484d9946ceaa9e3eed38151
commit r14-9972-g02cc8f3e68f9af96d484d9946ceaa9e3eed38151
Author: Robin Dapp
Date: Mon Apr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114668
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113479
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114717
--- Comment #5 from Thomas Schwinge ---
Distributions injecting some '-fcf-protection' by default could also inject
'-foffload-options=amdgcn-amdhsa=-fno-cf-protection' (or similar) to keep the
default case of offloading compilation working, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964
--- Comment #6 from Richard Biener ---
I think this has been fixed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108410
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 108410, which changed state.
Bug 108410 Summary: x264 averaging loop not optimized well for avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108410
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 108410, which changed state.
Bug 108410 Summary: x264 averaging loop not optimized well for avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108410
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110214
Bug 110214 depends on bug 108410, which changed state.
Bug 108410 Summary: x264 averaging loop not optimized well for avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108410
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110935
--- Comment #5 from Richard Biener ---
So ideally we could special-case the "output" of the SLP instance root. It
might be possible to insert the node just into the digraph.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114720
--- Comment #1 from GCC Commits ---
The master branch has been updated by J?rgen Kvalsvik :
https://gcc.gnu.org/g:18e881ebd9f4b9429c652a81b8ceee84275bdade
commit r14-9973-g18e881ebd9f4b9429c652a81b8ceee84275bdade
Author: Jørgen Kvalsvik
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964
--- Comment #7 from Matthias Kretz (Vir) ---
looks good to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
Ever confirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114721
Bug ID: 114721
Summary: libstdc++-v3/include/ext/codecvt_specializations.h: 2
* small performance tweeks
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
--- Comment #4 from Li Pan ---
(In reply to Kito Cheng from comment #3)
> Reduced case, not the final result, but it already run 8+ hours...
> ```
> typedef int a;
> typedef short b;
> typedef unsigned c;
> template < typename > using e = unsign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114722
Bug ID: 114722
Summary: Missed optimization: !e*d*e=>0, affected by useless
instructions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #31 from Richard Earnshaw ---
While that does seem to fix the bug, it's at the cost of 6 additional stores in
the problematic test that are redundant other than changing the alias set view.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114721
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-04-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114723
Bug ID: 114723
Summary: ICE when checking for type compatibility with
structure that contains flexible array member
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110006
Patrick Palka changed:
What|Removed |Added
Summary|[11/12/13 Regression] |[11/12 Regression] friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112769
Patrick Palka changed:
What|Removed |Added
Summary|[11/12/13 Regression] ICE |[11/12 Regression] ICE on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107168
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114706
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #25 from Jan Hubicka ---
So we have comdat groups that diverges in t1.o and t2.o. In one object it has
alias in it while in other object it does not
Merging nodes for _ZN6vectorI12QualityValueEC2ERKS1_. Candidates:
_ZN6vectorI12Qua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f8409c3109d2970a1fd63ac1a61601138b7ae46f
commit r14-9976-gf8409c3109d2970a1fd63ac1a61601138b7ae46f
Author: Jakub Jelinek
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 114689, which changed state.
Bug 114689 Summary: [14 Regression] libgcc/config/m68k/fpgnulib.c:305:
Suspicious coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #26 from Andrew Pinski ---
(In reply to Jan Hubicka from comment #25)
>
> If constexpr changes how the constructor is generated, isn't this violation
> of ODR?
Note the original code didn't have the constexpr change. And IIRC const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114720
Andrew Pinski changed:
What|Removed |Added
Component|gcov-profile|testsuite
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #27 from Jan Hubicka ---
OK, but the problem is same. Having comdats with same key defining different
set of public symbols is IMO not a good situation for both non-LTO and LTO
builds.
Unless the additional alias is never used by val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114722
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #28 from Jan Hubicka ---
So the main problem is that in t2 we have
_ZN6vectorI12QualityValueEC1ERKS1_/7 (vector<_Tp>::vector(const vector<_Tp>&)
[with _Tp = QualityValue])
Type: function definition analyzed alias cpp_implicit_alia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114724
Bug ID: 114724
Summary: [Regression]
libstdc++prettyprinters/debug.[cc|cxx11.cc] failing to
build
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78322
--- Comment #5 from David Blaikie ---
(In reply to Andrew Pinski from comment #4)
> (In reply to David Blaikie from comment #2)
> > (In reply to Richard Biener from comment #1)
> > > We produce an abstract copy for use by repeated inline copies.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114665
--- Comment #4 from Patrick O'Neill ---
Reran as requested in pr114668. Still present with that fix.
I'll triage some other testcases and file those as well. Hopefully one of them
is a duplicate to this one that is easily reproducible.
GCC: r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114725
Bug ID: 114725
Summary: Missed optimization: more precise range for and
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114724
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114724
--- Comment #2 from Carlos Eduardo Seo ---
OK, I'll reopen it there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114724
Carlos Eduardo Seo changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114625
--- Comment #5 from Ted Lyngmo ---
@Andrew, the title change seems wrong. It wrongly returns true when T{} is
ill-formed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
--- Comment #10 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:2a0c083558b4ac6609692294df7a388cf4468711
commit r14-9979-g2a0c083558b4ac6609692294df7a388cf4468711
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:2d694414ada8e3b58f504c1b175d31088529632e
commit r14-9978-g2d694414ada8e3b58f504c1b175d31088529632e
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
Jonathan Wakely changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749
Bug 106749 depends on bug 113386, which changed state.
Bug 113386 Summary: [C++23] std::pair comparison operators should be
transparent, but are not in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
What|Removed
1 - 100 of 182 matches
Mail list logo
