https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112683
--- Comment #2 from Richard Biener ---
Note copying more will likely trigger valgrind complaints accessing
uninitialized memory? Technically it also makes the IL to invoke
undefined behavior, if we'd expand this to byte-by-byte copies with
regi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112668
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9a96a9e45b421436ca93efadba0f1901f12fb6c0
commit r14-5815-g9a96a9e45b421436ca93efadba0f1901f12fb6c0
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112696
Bug ID: 112696
Summary: ICE When specializing auto... parameter pack with
typed pack
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112687
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112694
--- Comment #3 from JuzheZhong ---
Confirm it is RISC-V target issue.
Testing a patch which will fix all of them,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112693
Richard Biener changed:
What|Removed |Added
Component|middle-end |target
--- Comment #1 from Richard Bie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112696
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #45 from Tim Ruffing ---
Ha, I didn't want to move to discussion about restrict, but as a final remark:
The formal semantics of restrict are not easy to parse and understand (see
https://www.iso-9899.info/n3047.html#6.7.3.1 ). But jus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112694
--- Comment #4 from JuzheZhong ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638062.html
This patch fixes 200+ ICEs.
But we have these following ICEs left:
FAIL: gcc.dg/vect/pr71259.c -flto -ffat-lto-objects (internal compiler e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112668
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112619
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #13 from Surya Kumari Jangala ---
With the patch at
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631849.html, the
testcase gets shrink wrapped. This is the assembly produced:
addis 2,12,.TOC.-.LCF0@ha
addi 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112677
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
Bug ID: 112697
Summary: [14 Regression] 30-40% exec time regression of
433.milc on zen2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
--- Comment #1 from Filip Kastl ---
Around the same time there was also a 6% slowdown with
-Ofast -march=native -g and PGO
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=299.70.0
and an 11% slowdown with
-O2 -g -flto=128 and PGO
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96017
--- Comment #14 from Surya Kumari Jangala ---
Instead of using a non-volatile register to hold the value of foo, a volatile
register (r9) is assigned to hold foo. This avoids setting up the stack frame
in the fast path.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #46 from Richard Biener ---
I'll note that restrict on the parameters can help optimizing the copying loop
because you can then unroll and hoist loads before stores. I'll also note that
almost all (important) targets implement memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112353
--- Comment #3 from Robert ---
Thanks for the information!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
--- Comment #13 from Alexander Monakov ---
> Then there is the MULT_EXPR x * x case
This is PR 111701.
It would be nice to clarify what "nonnegative" means in the contracts of this
family of functions, because it's ambiguous for NaNs and negat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #2 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
--- Comment #14 from rguenther at suse dot de ---
On Fri, 24 Nov 2023, amonakov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
>
> --- Comment #13 from Alexander Monakov ---
> > Then there is the MULT_EXPR x *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
Bug ID: 112698
Summary: gcc-14-5617-gb8592186611 introduces regressions in
bfloat16_vector_typecheck_1.c for cortex-m0 and
cortex-m3
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #47 from Jakub Jelinek ---
(In reply to Richard Biener from comment #46)
> So yes, the most clean solution would be to have __forgiving_memcpy
> possibly also allowing NULL pointers when n == 0 besides allowing
> the exact overlap. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
--- Comment #13 from Richard Sandiford ---
In vect_create_constant_vectors, I think the uniform_elt needs
to come first, and needs to be used irrespective of whether the
number of elements is constant. The general tree_vector_builder
has a more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
--- Comment #1 from Christophe Lyon ---
For gcc.target/arm/bfloat16_vector_typecheck* tests, the log says:
FAIL: gcc.target/arm/bfloat16_vector_typecheck_1.c (test for excess errors)
Excess errors:
bfloat16_vector_typecheck_1.c:122:17: error: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
--- Comment #14 from Richard Biener ---
(In reply to Richard Sandiford from comment #13)
> In vect_create_constant_vectors, I think the uniform_elt needs
> to come first, and needs to be used irrespective of whether the
> number of elements is c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112677
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9f63a8898154473f7b773c3e2ed71e4959719b71
commit r14-5817-g9f63a8898154473f7b773c3e2ed71e4959719b71
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
Bug 86656 depends on bug 112677, which changed state.
Bug 112677 Summary: [14 Regression] ASAN reports stack-buffer-overflow in
tree-vect-loop.cc vect_is_simple_use when compiling with -mavx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112677
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112679
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:31669ec1d01c93fb0a63a7053ad314c17fa5a416
commit r14-5818-g31669ec1d01c93fb0a63a7053ad314c17fa5a416
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112699
Bug ID: 112699
Summary: Should limits.h in freestanding environment be
self-contained?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112673
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:eebcad0ac22010fc59de9d856bb02017fccab282
commit r14-5819-geebcad0ac22010fc59de9d856bb02017fccab282
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112673
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112679
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:3eb9cae6d375d222787498b15ac87f383b3834fe
commit r14-5822-g3eb9cae6d375d222787498b15ac87f383b3834fe
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112699
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112686
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112699
--- Comment #2 from Alexander Monakov ---
Sorry, even though GCC's limits.h is installed under include-fixed, it is
generated separately, not by the generic fixincludes mechanism. I was confused.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109977
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109977
--- Comment #5 from Sam James ---
If needed, you can email me an SSH key for a Neoverse-N1 (fp asimd evtstrm aes
pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
ssbs) which should be fast.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #8 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112686
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112694
--- Comment #5 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:aea337cf740ec33022f3cabfa7dd4333d5ba78ee
commit r14-5825-gaea337cf740ec33022f3cabfa7dd4333d5ba78ee
Author: Juzhe-Zhong
Date: Fri Nov 24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112699
--- Comment #3 from Xi Ruoyao ---
(In reply to Alexander Monakov from comment #1)
> Can you clarify which file you mean? gcc/ginclude does not have a limits.h.
>
> I assume you are not talking about the fixinclude'd limits.h?
No, I mean the li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99232
--- Comment #2 from CVS Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:726723c476800285cfbdfce612cedde4a9a7ad58
commit r14-5826-g726723c476800285cfbdfce612cedde4a9a7ad58
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112700
Bug ID: 112700
Summary: Segmentation fault with list of characters and types
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111408
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=108351
--- Comment #9 from Yann Girsberger ---
> Is this reduced from a real-world problem?
No, it is reduced from a modified csmith/random program.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
Bug ID: 112701
Summary: wrong type inference for ternary operator in
preprocessing context
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
--- Comment #7 from CVS Commits ---
The releases/gcc-12 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:f0445f4401c941d0aa3cc413ca4548f313cc1257
commit r12-10001-gf0445f4401c941d0aa3cc413ca4548f313cc1257
Author: Uros Bizjak
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:422e30e4d5ca2f26f77e7c90e09658408c07a23c
commit r11-1-g422e30e4d5ca2f26f77e7c90e09658408c07a23c
Author: Uros Bizjak
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|14.0|11.5
--- Comment #9 from Uroš Bizjak ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112702
Bug ID: 112702
Summary: C23, C++23: Extended characters not valid in an
identifier with -pedantic
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37
--- Comment #5 from CVS Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:4649121c8e3bae1315e265ad2e205990e39573c5
commit r13-8095-g4649121c8e3bae1315e265ad2e205990e39573c5
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111465
--- Comment #13 from CVS Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:152400decc8383aeff9a9ad8262b9e7e2fff61e0
commit r13-8096-g152400decc8383aeff9a9ad8262b9e7e2fff61e0
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37
Richard Biener changed:
What|Removed |Added
Known to fail||13.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112702
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
Andrew Pinski changed:
What|Removed |Added
CC||stammark at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112702
--- Comment #2 from Andrew Pinski ---
The answer is to is expected, the answer is YES.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
--- Comment #1 from Andrew Pinski ---
Interesting is MSVC emits both. clang emits none.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112300
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
--- Comment #2 from Andrew Macleod ---
It seems like we set 'e' to 3 immediately at the start:
[local count: 1073741824]:
e = 3;
goto ; [100.00%]
and it is never changed again. However, when we load from 'e' later in the IL
[local cou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112562
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112675
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112634
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112686
--- Comment #4 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:404ea4c1381398aee162415a88e5cb81c44f8c69
commit r14-5830-g404ea4c1381398aee162415a88e5cb81c44f8c69
Author: Uros Bizjak
Date: Fri N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112686
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #23 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:aae723d360ca26cd9fd0b039fb0a616bd0eae363
commit r14-5831-gaae723d360ca26cd9fd0b039fb0a616bd0eae363
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
Sam James changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111703
--- Comment #8 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:dd57446bd90c3225ce45e8818c5b00f2e86a9607
commit r13-8097-gdd57446bd90c3225ce45e8818c5b00f2e86a9607
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112269
--- Comment #14 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:dd57446bd90c3225ce45e8818c5b00f2e86a9607
commit r13-8097-gdd57446bd90c3225ce45e8818c5b00f2e86a9607
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939
--- Comment #11 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:cc4cbf38e842cf023e2bdc63a51ef836d7726d8e
commit r13-8098-gcc4cbf38e842cf023e2bdc63a51ef836d7726d8e
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111703
--- Comment #9 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:cc4cbf38e842cf023e2bdc63a51ef836d7726d8e
commit r13-8098-gcc4cbf38e842cf023e2bdc63a51ef836d7726d8e
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #24 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:c2dcfb6ba6e9a84a16e63ae73a822ae2a843170c
commit r14-5832-gc2dcfb6ba6e9a84a16e63ae73a822ae2a843170c
Author: Jan Hubicka
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #25 from Martin Jambor ---
(In reply to Richard Biener from comment #7)
> There is nothing to sink really, loop header copying introduces a PHI and
> there's not partial redundancies but only partial-partial and those are not
> obvio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
Sam James changed:
What|Removed |Added
Summary|[14 Regression] 30-40% exec |[14 Regression] 30-40% exec
th-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-5822-20231124121307-g3eb9cae6d37-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231124 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112606
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110794
John David Anglin changed:
What|Removed |Added
Last reconfirmed|2023-11-17 00:00:00 |2023-11-24
--- Comment #1 from John
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112704
Bug ID: 112704
Summary: FAIL: gcc.dg/analyzer/data-model-20.c (test for
warnings, line 17)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112705
Bug ID: 112705
Summary: FAIL: gcc.dg/analyzer/pr94688.c (test for excess
errors)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #48 from post+gcc at ralfj dot de ---
> Note, clang makes the same assumption apparently (while MSVC emits rep movs
> inline and ICC either that, or calls _intel_fast_memcpy).
MSVC does the same thing as clang and GCC, if godbolt is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112702
--- Comment #3 from Jonathan Wakely ---
It's also documented in the release notes:
https://gcc.gnu.org/gcc-13/changes.html#c (see N2836, Identifier Syntax using
Unicode Standard Annex 31).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112700
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112706
Bug ID: 112706
Summary: missed simplification in FRE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112706
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-11-24
Component|middle-en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #9 from Jakub Jelinek ---
Reproduced on powerpc64le-linux with just
../configure --enable-languages=c,c++ --enable-checking=yes,rtl,extra
--disable-libsanitizer --with-long-double-128; make -j160 profiledbootstrap
so fortunately does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112319
--- Comment #3 from CVS Commits ---
The master branch has been updated by Lewis Hyatt :
https://gcc.gnu.org/g:5d4abd9219dfa53b52b341255e99139bb6cad302
commit r14-5836-g5d4abd9219dfa53b52b341255e99139bb6cad302
Author: Lewis Hyatt
Date: Wed N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112319
Lewis Hyatt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112706
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> That is:
> ```
> (for op (eq ne)
> (simplify
> (op (pointer_plus @0 @1) (pointer_plus @0 @2))
> (op @1 @2))
>
> ```
Note I am missing a extra `)` but the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112706
--- Comment #3 from Jan Hubicka ---
Thanks, new pattern looks like noticeable improvement :)
Base+offset is effective for alias analysis and I suppose it happens
reasonably enough for compares as well.
> _76 = _71 + 4;
> # .MEM_154 = VDEF <.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112660
--- Comment #1 from gooncreeper ---
This could be further extended for signed integers as we can assume for left
shifts that shifted out bits are always 0 else UB, and always combine x << a >>
b.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112660
--- Comment #2 from Andrew Pinski ---
(In reply to gooncreeper from comment #1)
> This could be further extended for signed integers as we can assume for left
> shifts that shifted out bits are always 0 else UB, and always combine x << a
> >> b.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
--- Comment #15 from Jan Hubicka ---
With SRA improvements r:aae723d360ca26cd9fd0b039fb0a616bd0eae363 we finally get
good performance at -O2. Improvements to push_back implementation also helps a
bit.
Mainline with default flags (-O2):
Inpu
1 - 100 of 118 matches
Mail list logo