https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #8 from Jakub Jelinek ---
Unfortunately that would mean for the non-equality cases that if
lhs.undefined_p () we don't return undefined but false (aka VARYING).
Another option is to add those if (op?.undefined_p ()) return false; to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
Bug ID: 108658
Summary: [GCOV] Function entry is not recorded in a function
containing an infinite loop depending on the
optimization level
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #7 from Jakub Jelinek ---
So
--- gcc/range-op.cc.jj 2023-02-03 10:51:40.699003658 +0100
+++ gcc/range-op.cc 2023-02-03 16:04:39.264159294 +0100
@@ -642,7 +642,8 @@ operator_equal::op1_range (irange , tr
case BRS_FALSE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461
--- Comment #4 from CVS Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:534aea1ca7e7538dc6af3eac3cd2ec6c7343fdee
commit r12-9103-g534aea1ca7e7538dc6af3eac3cd2ec6c7343fdee
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #6 from Andrew Macleod ---
This is the first release that we process relations in GORI. Up until recently
it was fairly ad-hoc what got passed in as a relation trio to the op?_range
routines. A couple of days ago I fleshed it out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461
--- Comment #3 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:59e0376f607805ef9b67fd7b0a4a3084ab3571a5
commit r13-5684-g59e0376f607805ef9b67fd7b0a4a3084ab3571a5
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96745
Patrick Palka changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107150
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96745
Patrick Palka changed:
What|Removed |Added
Keywords||ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108579
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96745
--- Comment #6 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:ed2b519e02eac99fadfa51adc7b11f8854c24575
commit r13-5683-ged2b519e02eac99fadfa51adc7b11f8854c24575
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108579
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:e7930c6750d03b28d922ebbbace20ba9d8622c6a
commit r13-5682-ge7930c6750d03b28d922ebbbace20ba9d8622c6a
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925
--- Comment #10 from Tobias Burnus ---
I think that could be the commit
r12-5767-g6262e3a22b3d86afc116480bc59a7bb30b0cfd40
"fortran: Fix setting of array lower bound for named arrays"
but I have not checked more deeply.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925
Vladimir Fuka changed:
What|Removed |Added
CC||vladimir.fuka at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
Bug ID: 108657
Summary: csmith: possible wrong checksum with -O3 and
-ftrivial-auto-var-init=zero
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108435
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108637
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108656
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #5 from Aldy Hernandez ---
> Perhaps just adding if (op2.undefined_p ()) return false; above most of the
> switch (get_bool_state (r, lhs, type)) lines (in methods that refer to op2;
> and similarly for op1) for the comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
--- Comment #14 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:e8109bd87766be88e83fe88a44433dae16358a02
commit r13-5681-ge8109bd87766be88e83fe88a44433dae16358a02
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108646
--- Comment #3 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #2)
> It already does detect it:
>
> n.c: In function ‘test’:
> n.c:6:2: warning: argument 1 null where non-null expected [-Wnonnull]
> 6 | mem2(dest);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108656
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103934
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
--- Comment #1 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108656
--- Comment #1 from Arseny Solokha ---
The snapshot date is of course wrong. It should read "gcc 13.0.1 20230119
snapshot (g:2e32a12c04c72f692a7bd119fd3e4e5b74392c9d)".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108656
Bug ID: 108656
Summary: [12/13 Regression] '-fcompare-debug' failure (length)
w/ -O2 -fno-ipa-pure-const -fno-tree-dce --param
early-inlining-insns=0
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108655
--- Comment #1 from Jakub Jelinek ---
Created attachment 54401
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54401=edit
gcc13-pr108655.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108655
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Summary|ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108645
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> In your example, all your strings fit in the SSO buffer inside the
> std::string object, so the LHS has sufficient capacity for the result.
Actually that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108645
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> const auto __size = __lhs.size() + __rhs.size();
> if (__size > __lhs.capacity() && __size <= __rhs.capacity())
> return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #4 from Jakub Jelinek ---
Perhaps just adding if (op2.undefined_p ()) return false; above most of the
switch (get_bool_state (r, lhs, type)) lines (in methods that refer to op2; and
similarly for op1) for the comparison operators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104054
--- Comment #11 from Uroš Bizjak ---
The testcase now PASSes compare-debug with:
gcc version 13.0.1 20230203 (experimental) [master r13-5678-g167b04b9b8a] (GCC)
... but passes due to different register allocation, where regrename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108645
--- Comment #3 from Jonathan Wakely ---
(In reply to Evan Teran from comment #1)
> Which results in the same behavior, so it appears to be that the:
>
> ```
> basic_string operator+(basic_string &&, basic_string &&)
> ```
>
> Overload doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108646
--- Comment #2 from Jonathan Wakely ---
It already does detect it:
n.c: In function ‘test’:
n.c:6:2: warning: argument 1 null where non-null expected [-Wnonnull]
6 | mem2(dest);
| ^~
n.c:2:8: note: in a call to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
--- Comment #9 from Jakub Jelinek ---
So, the current state is that this is now optimized away by dom2 using frange,
like in PR107608 (which is closed with a workaround), but in this case the NaN
vs. 1.0
or NaN vs. Inf >= and <= comparisons get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108551
--- Comment #13 from Martin Liška ---
Thanks, I can confirm it's fine now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108655
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108655
Bug ID: 108655
Summary: ICE in execute_todo, at passes.cc:2134 since
r13-1204-gd68d366425369649
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108612
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108551
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #12 from Aldy Hernandez ---
Yeah, I've been mulling around the idea of removing the type from storage of
both irange and frange. It seems we need it for setting a type (setting the
endpoints for varying, querying HONOR_NANS,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #19 from Richard Biener ---
I have split out the SRA issue to PR108653.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108654
Bug ID: 108654
Summary: Incorrect codegen of RVV GCC
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108653
Bug ID: 108653
Summary: SRA compile-time hog with large copy chain
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-02-03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644
--- Comment #3 from Richard Biener ---
(In reply to Andrew Pinski from comment #1)
> The lto-plugin warnings are not a GCC issue really.
> ../../../gcc/lto-plugin/lto-plugin.c:501:19: warning: 'I' flag used with
> '%x' gnu_printf format
101 - 151 of 151 matches
Mail list logo
