https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
--- Comment #17 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #16)
> > Unfortunately, x86 has no vector mode .SAT_TRUNC instruction.
> No, AVX512 supports both signed and unsigned saturation
Indeed.
BTW: PACKUSmn (despite the name)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115963
--- Comment #1 from Andrew Pinski ---
Note most of the rest of the paragraphs around it say "If the value of the
operand of the delete-expression is not a null pointer value and .." The
question becomes is that an oversight of P3144R2 or not and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
Hongtao Liu changed:
What|Removed |Added
CC||lin1.hu at intel dot com
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115766
--- Comment #7 from Bi6c ---
(In reply to Sam James from comment #6)
> (In reply to Bi6c from comment #4)
> > Created attachment 58665 [details]
> > preprocessed file w/o csmith.h dependency
> >
> > Preprocessed file w/o csmith.h dependency
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110218
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908
Richard Biener changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115562
Christoph Müllner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115554
Christoph Müllner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115963
Bug ID: 115963
Summary: P3144R2 is not yet completely implemented
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #22 from Uroš Bizjak ---
(In reply to Sam James from comment #21)
> I think the instructions were for OP's benefit.
True ;)
@Maciej: I'd like to keep the testcase that also exercises the assembler,
because the error is best detecte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86869
Richard Biener changed:
What|Removed |Added
Target Milestone|14.1|14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
Richard Biener changed:
What|Removed |Added
Known to fail|14.0|
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
--- Comment #15 from Uroš Bizjak ---
(In reply to Li Pan from comment #14)
> Hi Uroš,
>
> > Please note two new instructions in the second asm dump. These are expanded
> > from .SAT_TRUNC and are not present in the first asm dump.
>
> > The pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115823
--- Comment #9 from Stefan Schulze Frielinghaus
---
Argh I forgot to add the isnormal optab for this PR. Just attached it. With
this I get for an unoptimized run
gm2 testisnormal.mod -O0 -S -c -fdump-tree-optimized
grep brasl testisnormal.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115823
--- Comment #8 from Stefan Schulze Frielinghaus
---
Created attachment 58689
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58689&action=edit
isnormal optab for s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115962
Kewen Lin changed:
What|Removed |Added
Severity|normal |enhancement
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115962
Bug ID: 115962
Summary: rs6000: Rework precision for 128bit float types and
modes
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: internal-improvement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112993
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112993
--- Comment #4 from GCC Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:fa86f510f51e6d940a28ea997fca3a6e3f50b4d3
commit r15-2086-gfa86f510f51e6d940a28ea997fca3a6e3f50b4d3
Author: Kewen Lin
Date: Wed Jul 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112993
--- Comment #2 from GCC Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:33dca0a4c1c421625cedb2d6105ef1c05f6b774e
commit r15-2084-g33dca0a4c1c421625cedb2d6105ef1c05f6b774e
Author: Kewen Lin
Date: Wed Jul 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112993
--- Comment #5 from GCC Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:b5c813ed6035cf6ef831927e66e184a5847afbe6
commit r15-2087-gb5c813ed6035cf6ef831927e66e184a5847afbe6
Author: Kewen Lin
Date: Wed Jul 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112993
--- Comment #3 from GCC Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:de6969fd311307e34904fc1f85603a9d92938974
commit r15-2085-gde6969fd311307e34904fc1f85603a9d92938974
Author: Kewen Lin
Date: Wed Jul 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112993
--- Comment #1 from GCC Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:3f6e6d4b408a26f69816f18d88dde4d983677488
commit r15-2083-g3f6e6d4b408a26f69816f18d88dde4d983677488
Author: Kewen Lin
Date: Wed Jul 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115766
Sam James changed:
What|Removed |Added
Keywords||needs-reduction
--- Comment #6 from Sam Jam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
--- Comment #5 from Li Pan ---
Thanks Andrew Pinski.
That make much sense to me, and I can reproduce this from upstream now. Let me
file a patch for it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115793
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115899
Xi Ruoyao changed:
What|Removed |Added
Resolution|INVALID |WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
--- Comment #14 from Li Pan ---
Hi Uroš,
> Please note two new instructions in the second asm dump. These are expanded
> from .SAT_TRUNC and are not present in the first asm dump.
> The problem here is that the presence of ustrunc{m}{n}2 optab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115899
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
--- Comment #4 from Andrew Pinski ---
(In reply to Li Pan from comment #3)
> Only x86 implemented the .SAT_TRUNC for scalar, so I bet it is almost the
> same as this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863 ?
No it is a different iss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #31 from waffl3x ---
(In reply to Gašper Ažman from comment #30)
> I don't really understand what you meant by "they have corresponding object
> parameters" - you mean that the object parameters are equal in both
> constraint and typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113711
Hongtao Liu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113733
Bug 113733 depends on bug 113711, which changed state.
Bug 113711 Summary: APX instruction set and instructions longer than 15 bytes
(assembly warning)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113711
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
--- Comment #3 from Li Pan ---
Only x86 implemented the .SAT_TRUNC for scalar, so I bet it is almost the same
as this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 99242, which changed state.
Bug 99242 Summary: [modules] ICE in lookup_mark, at cp/tree.c:2403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99242
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227
Bug 99227 depends on bug 99242, which changed state.
Bug 99242 Summary: [modules] ICE in lookup_mark, at cp/tree.c:2403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99242
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99242
Nathaniel Shead changed:
What|Removed |Added
Target Milestone|--- |14.2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99242
--- Comment #6 from GCC Commits ---
The releases/gcc-14 branch has been updated by Nathaniel Shead
:
https://gcc.gnu.org/g:5fad0b552c5851fb6ae6eb3616e50cc25af1391d
commit r14-10442-g5fad0b552c5851fb6ae6eb3616e50cc25af1391d
Author: Nathaniel She
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
--- Comment #10 from Ben Maurer ---
This appears to be fixed:
https://godbolt.org/z/r49nYx6df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
--- Comment #9 from GCC Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:6f2bab9b5d1ce1914c748b7dcd8638dafaa98df7
commit r15-2081-g6f2bab9b5d1ce1914c748b7dcd8638dafaa98df7
Author: Peter Bergner
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
--- Comment #8 from GCC Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:a05c3d23d1e1c8d2971b123804fc7a61a3561adb
commit r15-2080-ga05c3d23d1e1c8d2971b123804fc7a61a3561adb
Author: Peter Bergner
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115793
--- Comment #1 from Bi6c ---
When compiling with gcc-13.2.0 at -O0, -O1, -O2, -O3, and -Os, UBSAN reported
signed integer overflow error.
We wonder if the code was optimized out because of optimization level -O2, -O3,
and -Os in gcc-14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99242
--- Comment #5 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:1aa0f1627857c3e2d90982bdb07ca78ca10b26f3
commit r15-2079-g1aa0f1627857c3e2d90982bdb07ca78ca10b26f3
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #19 from Sam James ---
Created attachment 58688
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58688&action=edit
pass_diff_31_32.txt.xz
(In reply to Sam James from comment #18)
> The first point of divergence seems to be:
> [.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #18 from Sam James ---
The first point of divergence seems to be:
good:
```
(gdb) p unmapped_range
$59 = {minimum = -0.8701171875, middle = 0, maximum = 0.4000244140625}
(gdb) n
231 if (mapping.must_include ())
(gdb) p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #17 from Andrew Pinski ---
(In reply to Sam James from comment #14)
> ```
...
> @@ -299452,7 +299451,11 @@ Processing insn:
>REG_DEAD r477:SI
> Trying to simplify pattern:
> (zero_extend:SI (subreg:HI (reg:SI 477) 0))
> -Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115883
Hans-Peter Nilsson changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #16 from Sam James ---
By the way, the preprocessed source and so on are all from harfbuzz-8.5.0 as it
was easier to do some hacks with autotools.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #15 from Sam James ---
https://dev.gentoo.org/~sam/bugs/gcc/gcc-harfbuzz-dce/libharfbuzz_subset_la-hb-subset.cc.300r.ext_dce-dbgcnt-32.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #14 from Sam James ---
```
--- a/libharfbuzz_subset_la-hb-subset.cc.300r.ext_dce
+++ b/libharfbuzz_subset_la-hb-subset.cc.300r.ext_dce
@@ -299442,7 +299442,6 @@ Processing insn:
REG_DEAD r481:SI
Trying to simplify pattern:
(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #13 from Sam James ---
-fdbg-cnt=ext_dce:31 is fine, -fdbg-cnt=ext_dce:32 breaks. Thank you Andrew for
the debug counter!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115951
--- Comment #4 from GCC Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:73a8286d3ae266955fa921da1fa1328a587e7bb7
commit r15-2077-g73a8286d3ae266955fa921da1fa1328a587e7bb7
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #66 from Andrew Church ---
(In reply to Andrew Church from comment #65)
> As one of the advocates for this behavior, it stems (at least in my case)
> from pre-C23 code in which [[attribute]] syntax was not available. If
> [[nodiscard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #65 from Andrew Church ---
(In reply to Segher Boessenkool from comment #63)
> So you are asking the compiler to warn whenever you do not use the result
> of a function call, and at the same time you do not use the result of a
> funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #21 from Sam James ---
I think the instructions were for OP's benefit.
Anyway, thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #20 from Maciej W. Rozycki ---
Created attachment 58687
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58687&action=edit
Test case modified to use scan-assembler-times instead
(In reply to Uroš Bizjak from comment #17)
> (In r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115960
--- Comment #3 from Noah Williams ---
(In reply to Andrew Pinski from comment #2)
> Anyways this is not a GCC issue.
>
> The AttrBuilder::addAllocSizeAttr is declared in the preprocessed source
> as:
> AttrBuilder &addAllocSizeAttr(unsigned E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Ever con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
--- Comment #1 from Sergei Trofimovich ---
Forgot to post minimized example:
// $ cat a.cc
struct e { unsigned pre : 12; unsigned a : 4; };
static unsigned min_u(unsigned a, unsigned b) { return (b < a) ? b : a; }
__attribute__((noipa))
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115960
--- Comment #2 from Andrew Pinski ---
Anyways this is not a GCC issue.
The AttrBuilder::addAllocSizeAttr is declared in the preprocessed source as:
AttrBuilder &addAllocSizeAttr(unsigned ElemSizeArg,
const std:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
Bug ID: 115961
Summary: [15 Regression] wrong code on llvm-18.1.8 since
r15-1936-g80e446e829d818
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115823
--- Comment #7 from Gaius Mulley ---
I'm probably not testing in the same way as you - but I don't see the call to
isnormal with the following configure/build.
$ ~/opt/bin/s390x-linux-gm2 -v
Target: s390x-linux
Configured with: ../configure --p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115960
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115960
Bug ID: 115960
Summary: gcc throws an error when I use Optional in c++17.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115954
--- Comment #11 from Andrew Pinski ---
Can someone please raise this also to
https://github.com/ARM-software/abi-aa/issues ? Looks like the riscv folks are
ahead of the curve of defining the size/alignment here, see
https://github.com/riscv-non-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115749
--- Comment #12 from Roger Sayle ---
I owe Kim an apology. It does appear that modern x86_64 processors perform
(many) multiplications faster than the latencies given in the Intel/AMD/Agner
Fog documentation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115959
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115959
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115900
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #63 from Segher Boessenkool ---
(In reply to Christian Groessler from comment #62)
> (In reply to Segher Boessenkool from comment #60)
> > So you want to not warn for some (just *some*) explicitly unused cases, and
> > do
> > warn for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115959
Bug ID: 115959
Summary: [15 Regression] rv64gcv ICE: segfault during GIMPLE
pass: vect
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115950
--- Comment #2 from Andrew Pinski ---
Hmm actually there are patterns there but they are not matching. Something
seems to be going wrong with define_insn_and_rewrite ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115950
Andrew Pinski changed:
What|Removed |Added
Keywords||aarch64-sve
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115900
--- Comment #6 from Marek Polacek ---
This is beginning to make sense to me now.
Pre-r14-409: we're evaluating the call to C::C(), which is in the body of
B::B(), which is the body of D::D(&d):
C::C ((struct C *) this, NON_LVALUE_EXPR <0>)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643
--- Comment #15 from Sam James ---
H.J. has fixed this for upcoming binutils-2.43.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115954
--- Comment #10 from Andrew Pinski ---
https://gcc.gnu.org/legacy-ml/gcc/2019-08/msg00198.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115954
--- Comment #9 from Andrew Pinski ---
Note this was raised on the LLVM side back in 2016:
https://github.com/llvm/llvm-project/issues/26836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115954
--- Comment #8 from Andrew Pinski ---
https://gcc.gnu.org/legacy-ml/gcc/2019-08/msg00191.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109867
Arsen Arsenović changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115781
--- Comment #2 from anlauf at gcc dot gnu.org ---
Interesting observation: replacing
call use_mats(mats)
by
call use_mats(mats(lbound(mats,1):))
leads to apparently correct output:
top level: mats, lbound= 2, ubound= 4
top level, 2:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108643
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115781
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115942
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115942
Manuel Lauss changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115884
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110159
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |dinka.ranns at gmail
dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110159
--- Comment #1 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:40a990c8b512fd25bd7d7b45aa509e1880d77209
commit r15-2076-g40a990c8b512fd25bd7d7b45aa509e1880d77209
Author: Nina Ranns
Date: Thu J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336
Arsen Arsenović changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115935
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115958
Bug ID: 115958
Summary: varasm.cc:8546:27: error: comparison of integer
expressions of different signedness
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101133
Arsen Arsenović changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323
--- Comment #8 from Arsen Arsenović ---
iota did come to mind while I was typing that, but my thinking is that it is
far more likely to be unintended, hence my thinking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323
--- Comment #7 from Enrico Maria De Angelis ---
(In reply to Arsen Arsenović from comment #6)
> is it possible to implement any correct terminating coroutine within those
> restrictions?
Is it a requirement that a coroutine must be terminate-ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105301
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
Reso
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115896
--- Comment #4 from Gabriel Ravier ---
I'll add that the case of `(a << cst0) == cst1` (which LLVM handles but not
GCC) seems relatively frequent in real code, e.g. after a few minutes I've
found it in:
-
https://github.com/TASEmulators/BizHawk/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #12 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #11)
> Note it might also be useful to add dbgcnt.def support to ext-dce.cc. If I
> get a chance I might add it too.
I have a patch which implements this; just test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115896
--- Comment #3 from Gabriel Ravier ---
(PS: LLVM seems to do the `(cst0 << a) == cst1` transformation including when
`cst1 == 0` since 59939acd2684708a1c617f9e42b2206956804bb6)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115896
--- Comment #2 from Gabriel Ravier ---
Also somewhat of an opposite to `(a << cst0) == cst1` is `(cst0 << a) == cst1`,
which seems to be optimized by GCC in certain cases but not for `cst1 == 0`,
which LLVM does for e.g.:
#include
bool f3(int
1 - 100 of 216 matches
Mail list logo
