https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108985
--- Comment #1 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:a2926653ebbc88e8bba335563fa86b44651598d6
commit r13-6406-ga2926653ebbc88e8bba335563fa86b44651598d6
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108985
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f0ef740d54f47ff614eb02e13e8f4cb11dfbb140
commit r13-6407-gf0ef740d54f47ff614eb02e13e8f4cb11dfbb140
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:cc88366a80e35b3e53141f49d3071010ff3c2ef8
commit r13-6408-gcc88366a80e35b3e53141f49d3071010ff3c2ef8
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13 Regression] |[12 Regression]
|bit_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #12 from Martin Liška ---
(In reply to Marek Polacek from comment #11)
> No, because as Comment 9 says, there's no good way to suppress the warning.
> I'm currently leaning towards closing the BZ and suggesting adding a #pragma
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #15 from Costas Argyris ---
Sounds like I am hitting a separate existing limitation that has nothing to do
with this bug.
Do we need a new bug report for that one then?
FWIW, gcc/config.host wasn't doing anything with host_extra_ob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
--- Comment #5 from Jonathan Wakely ---
(In reply to Jiang An from comment #3)
> I've mailed to LWG Chair for this...
Thanks, the new issue will be opened soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
Richard Biener changed:
What|Removed |Added
Known to fail||12.2.0, 13.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108987
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108430
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:2a8ce4b52f5892a10a02b94d7be689e59a444ff6
commit r13-6409-g2a8ce4b52f5892a10a02b94d7be689e59a444ff6
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108603
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:b09dc74801cf4e19bdf5fcd18a5cd53fc9e9ca9a
commit r13-6410-gb09dc74801cf4e19bdf5fcd18a5cd53fc9e9ca9a
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #20 from Giuseppe D'Angelo ---
Thanks for the patch!
Should ranges_algobase.h also be similarly changed? There's a memmove in its
copy/move code as well:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/ran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108430
--- Comment #4 from rsandifo at gcc dot gnu.org
---
Fixed on trunk, but the underlying bug is present in GCC 12 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976
--- Comment #2 from Dimitrij Mijoski ---
(In reply to Dimitrij Mijoski from comment #0)
> Those that read from UCS-2 seem to me like they properly report the error.
> Reading from UTF-16 can not have this bug by definition. From what I
> checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976
--- Comment #3 from Jonathan Wakely ---
I have some new code for handling UTF-8 for std::print, and using that code
your relaxed u8str gets converted to 12 U+FFFD code points when printed to a
terminal, which I think is correct.
#include
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #21 from Jonathan Wakely ---
Indeed it should.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108738
--- Comment #7 from Richard Biener ---
So it's now better than before but still quadratic.
Finding a strathegic place to limit the search with some --param might be a
solution, but there's no easy
point to hook that into. You'd not want to dis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108979
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770
--- Comment #10 from Surya Kumari Jangala ---
The swap pass analyzes vector computations and removes unnecessary doubleword
swaps (xxswapdi instructions). The swap pass first constructs webs and removes
swap instructions if possible. If the web
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108989
Bug ID: 108989
Summary: Two small almost identical programs give different
results
Product: gcc
Version: og10 (devel/omp/gcc-10)
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681
tt_1 changed:
What|Removed |Added
CC||herrtimson at yahoo dot de
--- Comment #13 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Known to work|12.2.1 |
--- Comment #14 from rsa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770
--- Comment #11 from Segher Boessenkool ---
(In reply to Jens Seifert from comment #6)
> The left part of VSX registers overlaps with floating point registers, that
> is why no register xxpermdi is required and mfvsrd can access all (left)
> par
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108989
Andreas Schwab changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97956
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:62a8d31ecc07041af4a81353c2d57d9845c4b771
commit r13-6414-g62a8d31ecc07041af4a81353c2d57d9845c4b771
Author: Jonathan Yong <10wa...@gm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108990
Bug ID: 108990
Summary: Too restrictive precision check in fold and simplify
pattern for PR70920
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108953
--- Comment #3 from Jakub Jelinek ---
BTW, I've tried:
struct A
{
unsigned char a, b, c, d;
unsigned short e, f;
int g;
bool operator== (A const &) const = default;
};
struct B
{
unsigned char b;
bool operator== (B const &) const =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108963
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2023-03-02
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108972
Martin Liška changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
Sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #7 from Martin Uecker ---
An attribute is certainly simpler and should be easy to add.
I proposed similar extension for C23 and there was some interest,
but I did not have time to follow up.
https://www.open-std.org/jtc1/sc22/wg14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106259
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:71afd0628419c5d670701cb35bc9860380c7d9fb
commit r13-6417-g71afd0628419c5d670701cb35bc9860380c7d9fb
Author: Marek Polacek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106259
Marek Polacek changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108542
Marek Polacek changed:
What|Removed |Added
Priority|P1 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #13 from Marek Polacek ---
I would really not like to do that, the false positives rate is pretty low.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108979
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:076d309e36c682176e9f85dc8593e6f2c9e6e75f
commit r13-6418-g076d309e36c682176e9f85dc8593e6f2c9e6e75f
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108979
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #10 from Alexander Monakov ---
(In reply to Rui Ueyama from comment #9)
> I'm the maintainer of the mold linker. I didn't implement that POWER10 ABI
> because I didn't have an access to a POWER10 machine and therefore couldn't
> veri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62196
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108991
Bug ID: 108991
Summary: [13 regression] gcc.dg/memchr-3.c fails after
r13-6414-g62a8d31ecc0704
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
Bug ID: 108992
Summary: Regression: Branch direction canonicalization leads to
pointless tail duplication / CSE/sinking by inverting
branch
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #7)
> An attribute is certainly simpler and should be easy to add.
yes.
>
> I proposed similar extension for C23 and there was some interest,
> but I did
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
Bug ID: 108993
Summary: Value initialization does not occur for derived class
with -Os, for gcc versions > 5
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
Bug ID: 108994
Summary: LLVM JIT segfaults in libgcc after upgrading from gcc
12.2.1 to 13.0.1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #9 from Martin Uecker ---
Am Donnerstag, dem 02.03.2023 um 17:34 + schrieb qinzhao at gcc dot
gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #8 from qinzhao at gcc dot gnu.org ---
> (In reply to M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108716
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:4d82022bfd15d36717bf60a11e75e9ea02204269
commit r13-6419-g4d82022bfd15d36717bf60a11e75e9ea02204269
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
Jonathan Wakely changed:
What|Removed |Added
Summary|LLVM JIT segfaults in |[13 Regression] LLVM JIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108716
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107060
--- Comment #9 from David Malcolm ---
Reconfirming, alas. I just tried adding emacs to my integration test suite
[1], and xdisp.c is still a big outlier, taking ~15 minutes; with gcc (GCC)
13.0.1 20230202 (experimental).
[1] https://github.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #10 from Martin Uecker ---
And to get bounds checking for the flexible array member today,
one could use a macro to attach the bound back to the array
on member access.
https://godbolt.org/z/GbaoYrhav
But the bound from the type i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108995
Bug ID: 108995
Summary: Missed signed integer overflow checks in UBsan?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #7 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:20bd258d0fa09837b3a93478ef92d8789cbcd442
commit r13-6420-g20bd258d0fa09837b3a93478ef92d8789cbcd442
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108243
--- Comment #12 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:cbaa1d9c218d9c0b5e34e510a462ff4e299a0f3f
commit r13-6421-gcbaa1d9c218d9c0b5e34e510a462ff4e299a0f3f
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108243
--- Comment #13 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:5425159d176a7a92afc932cbb22d8822667099c4
commit r13-6422-g5425159d176a7a92afc932cbb22d8822667099c4
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97553
--- Comment #7 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:5425159d176a7a92afc932cbb22d8822667099c4
commit r13-6422-g5425159d176a7a92afc932cbb22d8822667099c4
Author: Patrick Palka
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #1 from Andrew Pinski ---
Can you supply the output of "gcc -v"?
There was a bug dealing with the unwinder which wad fixed in the last month.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #2 from Tom Stellard ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-redhat-linux/13/lto-wrapper
Target: aarch64-redhat-linux
Configured with: ../configure --enable-bootstrap
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
--- Comment #1 from Andrew Pinski ---
Why do you think this is a bug?
I don't see anything wrong with the newer versions of gcc.
Duplicating the basic blocks is done on purpose for speed reasons.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-03-02
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #9)
>
> https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log
thanks for the info.
>
> But we made variably modified types mandatory in C23 to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
--- Comment #2 from Nikita Kniazev ---
> Why do you think this is a bug?
> I don't see anything wrong with the newer versions of gcc.
> Duplicating the basic blocks is done on purpose for speed reasons.
I understand that removing diamonds is do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108243
Patrick Palka changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #9)
>
> Here, we want to use a member of the struct as a size
> expression. This could work equally at function and file scope.
> But the semantics need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #13 from Martin Uecker ---
Am Donnerstag, dem 02.03.2023 um 19:47 + schrieb qinzhao at gcc dot
gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #11 from qinzhao at gcc dot gnu.org ---
> (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #3 from Andrew Pinski ---
Maybe related to :
r13-2801-g94ccaf62c378c3
r13-2870-g386ebf75f4c034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
Bug ID: 108996
Summary: Proposal for adding DWARF call site information got
GCC with -O0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #9 from Andrew Cooper ---
Thank-you for the fix.
I've recompiled master and this uninitialised warning has gone.
Unfortunately, Xen isn't GCC-13 clean (seems like a real bug in Xen), and the
analyser has pointed out various other t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #10 from Andrew Cooper ---
>From trying this out, a const attribute doesn't alter the code generation in
the slightest, so I presume GCC has already figured the const-ness out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #11 from David Malcolm ---
(In reply to Andrew Cooper from comment #9)
[...snip...]
> Would a const annotation on get_cpu_info() be likely to help? It occurs to
> me that this is true in all cases that the compiler could legitimatel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #12 from David Malcolm ---
(In reply to Andrew Cooper from comment #9)
[...snip...]
> Our code does fundamentally rely on get_cpu_info() always returning the same
> pointer (on a single CPU). For example, `current` is defined as
> `
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #13 from Andrew Cooper ---
I've constructed an example which might be the knockon effect you were worried
about?
void foo(char *other)
{
char *ptr = NULL;
if ( current->domain )
ptr = other;
asm volatile ("cmc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
Patrick Palka changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #14 from Andrew Cooper ---
Created attachment 54572
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54572&action=edit
Preprocessed example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #15 from Andrew Cooper ---
Wow that's a lot of junk getting included for the minimal include set I could
easily make.
It occurs to me only after posting that you're liable to fail at:
asm ( ".include \"arch/x86/include/asm/asm-ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #16 from David Malcolm ---
Minimized version of attachment 54572:
struct cpu_info {
/* [...snip...] */
struct vcpu *current_vcpu;
/* [...snip...] */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #17 from David Malcolm ---
...where trunk emits:
test.c:35:22: warning: dereference of NULL 'ptr' [CWE-476]
[-Wanalyzer-null-dereference]
35 | ptr[0] = ~ptr[0];
| ~~~^~~
'foo': events 1-6
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #18 from David Malcolm ---
Looks like it doesn't even need the asm stmt at line 32 to consider that it
could take the false-then-true path.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856
--- Comment #6 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-March/059003.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706
--- Comment #18 from CVS Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:2639f9d2313664e6b4ed2f8131fefa60aeeb0518
commit r13-6424-g2639f9d2313664e6b4ed2f8131fefa60aeeb0518
Author: Vladimir N. Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84471
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107504
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
--- Comment #3 from Andrew Pinski ---
Did you see this in real code or you just noticed this while looking at code
generation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997
Bug ID: 108997
Summary: GCC prediction on bool comparisons seems wrong
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:6b432c0f777ab9b8436fb07f71de6ea4d259b869
commit r13-6425-g6b432c0f777ab9b8436fb07f71de6ea4d259b869
Author: Guillaume Gomez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
--- Comment #5 from Andrew Pinski ---
Note I filed PR 108997 for what seems like the wrong heurstic for the
prediction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108990
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
--- Comment #6 from Nikita Kniazev ---
> Did you see this in real code or you just noticed this while looking at code
> generation?
If you mean do I have any benchmark - unfortunately no. I noticed it for a
while by poking different code to co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
--- Comment
1 - 100 of 160 matches
Mail list logo
