https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #30 from post+gcc at ralfj dot de ---
There have been several assertions above that a certain way to solve this
either has no performance cost at all or severe performance cost. That sounds
like we are missing data -- ideally, someone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112675
Bug ID: 112675
Summary: [14 Regression] r14-5385-g0a140730c97087 caused
regression on testcases
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
--- Comment #12 from Richard Biener ---
Created attachment 56668
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56668=edit
patch (not working)
So this tries this, moving the duplicate-and-interleave check and changing
code generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #31 from Richard Biener ---
(In reply to Patrick J. LoPresti from comment #29)
> (In reply to Jakub Jelinek from comment #27)
> >
> > No, that is not a reasonable fix, because it severely pessimizes common code
> > for a theoretical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112676
Bug ID: 112676
Summary: [14 regression] ICE in extract_insn, at recog.cc:2804
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
--- Comment #8 from Li Pan ---
For gcc.dg/torture/pr58955-2.c, we can simply reproduce it by options
Pass when: -O3
Pass when: -O3 -ftracer -fno-schedule-insns -fno-schedule-insns2
Fail when: -O3 -ftracer -fno-schedule-insns2
10154:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
--- Comment #24 from Haochen Jiang ---
Patch aims to fix that:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637865.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
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=112643
--- Comment #25 from urs at akk dot org ---
(In reply to Haochen Jiang from comment #24)
> Patch aims to fix that:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637865.html
Yes, that solved the issue for me. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112668
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2023-11-22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671
--- Comment #3 from Arsen Arsenović ---
hm, actually, I think I confused reports - sorry.
do you know if this worked a short while ago? and if so, how did such a
configuration look?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #27 from Jakub Jelinek ---
(In reply to Rich Felker from comment #26)
> > The only reasonable fix on the compiler side is to never emit memcpy but
> > always use memmove.
>
> No, it can literally just emit (equivalent at whatever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #30 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:990769a343f090088f5025ad233f88824b2c6263
commit r14-5769-g990769a343f090088f5025ad233f88824b2c6263
Author: Pan Li
Date: Mon Nov 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106120
--- Comment #13 from CVS Commits ---
The master branch has been updated by Hans-Peter Nilsson :
https://gcc.gnu.org/g:e935151bad1c2a02dc6a31fce3cc21b17d616243
commit r14-5767-ge935151bad1c2a02dc6a31fce3cc21b17d616243
Author: Hans-Peter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112336
--- Comment #3 from Jakub Jelinek ---
Seems one doesn't need the sanitizer for that,
unsigned _BitInt(1) v1;
unsigned _BitInt(1) *p1 =
ICEs as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112592
--- Comment #2 from CVS Commits ---
The master branch has been updated by John David Anglin :
https://gcc.gnu.org/g:6f59f959e751d73b371d52f9c657f78d7a77983c
commit r14-5765-g6f59f959e751d73b371d52f9c657f78d7a77983c
Author: John David Anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #8 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #7)
> Alternatively, if IPA could figure out when things need promoting.. GCC
> must already do it, although I suppose thats in the front ends :-P
Well, in this
ed LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231122 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112633
--- Comment #4 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:3f266c84a15d63e42bfad46397fea9aff92b0720
commit r14-5763-g3f266c84a15d63e42bfad46397fea9aff92b0720
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112633
--- Comment #6 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:63c65224e778124eee52acc7b9fcb32cd8ad61e8
commit r13-8090-g63c65224e778124eee52acc7b9fcb32cd8ad61e8
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #6 from Jakub Jelinek ---
I don't know the IPA code enough to know whether different operand_type vs.
param_type (in the !types_compatible_p sense) means just user bug (in that case
returning VARYING is perfectly fine), or if it can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112617
John David Anglin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #5)
> Just changing
> --- i386.md.xx2023-11-22 09:47:22.746637132 +0100
> +++ i386.md 2023-11-22 20:38:07.216218697 +0100
> @@ -9984,7 +9984,7 @@
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112674
--- Comment #1 from Jeffrey A. Law ---
And possibly more interesting than the compare-debug failure is this patch
seems to be causing Wstringop-overflow-17 to fail on multiple targets,
including c6x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506
Gaius Mulley changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Gaius
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #46 from CVS Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:4f1ebd54380e16927cd0085be939165870354eac
commit r14-5768-g4f1ebd54380e16927cd0085be939165870354eac
Author: Costas Argyris
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112464
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #29 from Patrick J. LoPresti ---
(In reply to Jakub Jelinek from comment #27)
>
> No, that is not a reasonable fix, because it severely pessimizes common code
> for a theoretical only problem.
The very existence of (and interest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112592
John David Anglin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-5761-20231122145100-ge9b39df9333-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231122 (experimental) (GCC)
At the asm output, the problem is obvious:
m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112336
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=112445
--- Comment #6 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #4)
> I think this goes wrong during combine.
Combine does not / should not combine moves from hard registers just because of
extending register live range. It looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112642
--- Comment #10 from Jonathan Wakely ---
(In reply to Miro Palmu from comment #9)
> Mine is 13.2.1 20230801 so way before Oct 21. (I did not know there were
> different snapshots of the releases, I'm just a user trying to help :) )
13.2.1 (and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
--- Comment #5 from Julian Waters ---
Note: Trying this with a top level asm gives me:
$ g++ -O3 -flto=auto -std=c++14 -pedantic -Wpedantic -fno-omit-frame-pointer
exceptions.cpp
exceptions.cpp:8:1: error: expected unqualified-id before 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510
--- Comment #17 from Vladimir Sadovnikov ---
Reproducible with 11.4.0
~$ export ASAN_OPTIONS=detect_stack_use_after_return=1
~$ g++ -fsanitize=address -Og test-case.cpp
~$ ./a.out
Aborted (core dumped)
~$ gcc --version
gcc (Ubuntu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #7 from Andrew Macleod ---
Explicit casts would be no problem as they go through the proper machinery. The
IL for that case has an explicit cast in it.
_1 = (int) x_2(D);
foo (_1);
its when that cast is not present,and we try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112617
--- Comment #4 from CVS Commits ---
The master branch has been updated by John David Anglin :
https://gcc.gnu.org/g:a89224f819381b77657145fdd8b1d997b989fdc0
commit r14-5764-ga89224f819381b77657145fdd8b1d997b989fdc0
Author: John David Anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
--- Comment #5 from Jakub Jelinek ---
Just changing
--- i386.md.xx 2023-11-22 09:47:22.746637132 +0100
+++ i386.md 2023-11-22 20:38:07.216218697 +0100
@@ -9984,7 +9984,7 @@
[(set (match_operand: 0 "register_operand" "=r,A")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #31 from Li Pan ---
We still have some unnecessary code here, which is stack-related, will take
care of it in another PATCH.
After this patch:
test:
lui a5,%hi(.LANCHOR0)
addia5,a5,%lo(.LANCHOR0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112669
Thomas Schwinge changed:
What|Removed |Added
Last reconfirmed||2023-11-22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> Well, in this case the user explicitly told compiler not to do that by not
> using a prototype and syntax which doesn't provide one from the definition.
> It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:4f1ebd54380e16927cd0085be939165870354eac
commit r14-5768-g4f1ebd54380e16927cd0085be939165870354eac
Author: Costas Argyris
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #28 from Rich Felker ---
> No, that is not a reasonable fix, because it severely pessimizes common code
> for a theoretical only problem.
Far less than a call to memmove (which necessarily has something comparable to
that and other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112633
--- Comment #5 from Hana Dusíková ---
Thanks for really quick fix! You are awesome!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112670
--- Comment #1 from Robin Dapp ---
The problem is exposed with the ipa copy propagation pass. I haven't narrowed
it down yet but will continue tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112674
Bug ID: 112674
Summary: [14 Regression] Compare-debug failure after recent
change on c6x
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Andrew Pinski changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112464
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
--- Comment #3 from Andrew Pinski ---
parityhi2 should have:
rtx extra = gen_reg_rtx (HImode);
emit_move_insn (extra, operands[1]);
emit_insn (gen_parityhi2_cmp (extra));
Or something similar because parityqi2_cmp clobbers its argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #5 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #4)
>
> I think
> Value_Range vr (operand_type);
> if (TREE_CODE_CLASS (operation) == tcc_unary)
> ipa_vr_operation_and_type_effects (vr,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112344
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=112657
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Andrew Pinski from comment #2)
>
> > Someone will have to debug ifcvt.cc to see why it fails on x86_64 but works
> > on aarch64. Note there are some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110879
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106120
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Hans-Peter Nilsson ---
> (In reply to Rainer Orth from comment #10)
>> Since 20230106, this test produces an XPASS, according to gcc-testresults
>> postings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #5 from Uroš Bizjak ---
Digging a bit further:
if_info.max_seq_cost is calculated via targetm.max_noce_ifcvt_seq_cost, where
without params set we return:
return BRANCH_COST (true, predictable_p) * COSTS_N_INSNS (2);
with:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #6 from Uroš Bizjak ---
This is by design, CMOV should not be used instead of well predicted jumps.
FYI, CMOV is quite problematic on x86, there are several PRs where conversion
to CMOV resulted in 2x slower execution. Please see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112667
Bug ID: 112667
Summary: [OpenMP] C++: Handle static local variable in target
regions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openmp,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111971
Jiu Fu Guo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #3 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #2)
> Someone will have to debug ifcvt.cc to see why it fails on x86_64 but works
> on aarch64. Note there are some new changes to ifcvt.cc in review which
> might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112666
Bug ID: 112666
Summary: Missed optimization: Value initialization
zero-initializes members with user-defined constructor
Product: gcc
Version: 11.4.0
Status:
ersion 14.0.0 20231122 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
--- Comment #23 from Haochen Jiang ---
I have root caused the issue and also discovered some other minor problems
unrelated to this PR but hard to discover.
I will write a patch to fix all of them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112518
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112526
Jakub Jelinek changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112669
Bug ID: 112669
Summary: GCN: wrong 'LIBRARY_PATH' in presence of several
different '-march=[...]' flags
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
Richard Biener changed:
What|Removed |Added
Summary|[14] RISC-V ICE: in |[14] RISC-V ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112563
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Jakub Jelinek ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #9)
[...]
>> I've now come up with an alternative. It's a bit ugly, but it gets the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112670
Bug ID: 112670
Summary: RISC-V: Run fail on pr65518.c with -flto
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112668
--- Comment #1 from Jakub Jelinek ---
Reduced:
/* PR middle-end/112668 */
/* { dg-do compile { target bitint } } */
/* { dg-options "-std=c23 -fnon-call-exceptions" } */
#if __BITINT_MAXWIDTH__ >= 495
struct T495 { _BitInt(495) a : 2; unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112518
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8c24011b2ba0f268e74b72519fc8119c2c99d92b
commit r14-5752-g8c24011b2ba0f268e74b72519fc8119c2c99d92b
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
--- Comment #14 from Gianfranco ---
Hello, any news for this issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112642
--- Comment #8 from Jonathan Wakely ---
(In reply to Miro Palmu from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > The examples in comment 4 do compile using libstdc++ on clang, if you use
> > libstdc++ headers from after sept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112668
--- Comment #2 from Jakub Jelinek ---
No loop is needed:
/* PR middle-end/112668 */
/* { dg-do compile { target bitint } } */
/* { dg-options "-std=c23 -fnon-call-exceptions" } */
#if __BITINT_MAXWIDTH__ >= 495
struct T495 { _BitInt(495) a :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112563
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Jakub Jelinek ---
> So, shall we go with
> --- libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h.jj
> 2023-11-15 12:45:17.359586776 +0100
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
--- Comment #6 from JuzheZhong ---
Hi, there are these following run FAILs left on RV32/RV64 C/C++:
after this patch fix:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637753.html
FAIL: gcc.dg/vect/pr65518.c -flto -ffat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644
--- Comment #4 from Tamar Christina ---
I've asked Matthew to take a look since he wrote the initial support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112666
--- Comment #1 from Jonathan Wakely ---
(In reply to Francisco Paisana from comment #0)
> The struct "C" which is just "B" and an int is much slower at being
> initialized than B when value initialization (via {}) is used. However, my
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110158
--- Comment #9 from Jonathan Wakely ---
Odd, I thought I'd checked it when testing r14-4334-g28adad7a32ed92.
Seems like the same issue as PR 112642 though (which has a minimized version
without std::string).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112563
--- Comment #10 from Jakub Jelinek ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #9)
> > --- Comment #8 from Jakub Jelinek ---
> > So, shall we go with
> > --- libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h.jj
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
--- Comment #8 from Richard Sandiford ---
I think we're going down the wrong path here. If I've understood
the original change correctly, dummy masks aren't special because
they're masks. They're special because all elements are equal to
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112344
--- Comment #9 from Richard Biener ---
In particular the final jump is miscalculated somehow, possibly path-ranger
mishandles the situation. For the loop header we thread through we
first clear dependent ranges (good) but then do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112642
--- Comment #7 from Miro Palmu ---
(In reply to Jonathan Wakely from comment #6)
> The examples in comment 4 do compile using libstdc++ on clang, if you use
> libstdc++ headers from after sept 29 (for trunk) or oct 21 (for gcc-13).
I was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112669
--- Comment #1 from Thomas Schwinge ---
Tracing through 'gcc/gcc.cc': 'build_search_list' -> 'for_each_path', I find:
For '-march=gfx908', we have:
(gdb) print multilib_dir
$3 = 0x82e6c0 "gfx908"
(gdb) print multilib_os_dir
$4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
--- Comment #7 from Richard Biener ---
diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index 4a09b3c2aca..d0967240ae3 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -766,7 +766,10 @@ vect_get_and_check_slp_defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98925
--- Comment #3 from Jan Hubicka ---
Return value range propagation was added in
r:53ba8d669550d3a1f809048428b97ca607f95cf5
however it works on scalar return values only for now. Extending it to
aggregates is a logical next step and should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
--- Comment #5 from Jan Hubicka ---
> but the issue is that test2 escapes which makes this conflict:
It is passed to memmove which is noescape and returned. Why local PTA
considers returned values to escape?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112611
--- Comment #4 from Xi Ruoyao ---
(In reply to Jiahao Xu from comment #3)
> We now consider it as undefined behavior rather than a bug for [x]vshuf
> instructions. In vec_perm pattern, we use vector logical AND instructions to
> perform modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
--- Comment #4 from Richard Biener ---
We do use the alias oracle in folding memmove:
/* If the destination and source do not alias optimize into
memcpy as well. */
if ((is_gimple_min_invariant (dest)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644
--- Comment #5 from Jakub Jelinek ---
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110879
--- Comment #4 from Jonathan Wakely ---
Ah I think that's probably expected. In _M_realloc_insert (and now
_M_realloc_append) we have:
#if __cplusplus >= 201103L
if _GLIBCXX17_CONSTEXPR (_S_use_relocate())
{
//
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
--- Comment #6 from Richard Biener ---
As suggested in the review at time the change would ideally be restricted to
actual mask operands, not random BOOLEAN_TYPE ones.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
--- Comment #7 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:de6f3e12bd188fee30bc79a5e323e16e0dbbe8ca
commit r14-5755-gde6f3e12bd188fee30bc79a5e323e16e0dbbe8ca
Author: Juzhe-Zhong
Date: Wed Nov
1 - 100 of 117 matches
Mail list logo
