https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113898
Bug ID: 113898
Summary: ICE in copy_reference_ops_from_ref, at
tree-ssa-sccvn.cc:1156
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
Tamar Christina changed:
What|Removed |Added
Component|middle-end |tree-optimization
Priority|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113852
--- Comment #8 from rguenther at suse dot de ---
On Mon, 12 Feb 2024, admin at computerquip dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113852
>
> --- Comment #7 from Zachary L ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #39 from Richard Biener ---
(In reply to H.J. Lu from comment #32)
> (In reply to Michael Matz from comment #31)
> > (In reply to H.J. Lu from comment #30)
> > > (In reply to Michael Matz from comment #29)
> > > > It not only can cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899
Bug ID: 113899
Summary: Vect module test failures while running on remote host
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-02-13
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-02-13
Keywords|needs-bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113898
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #26 from Sam James ---
I was using it in one of the testcases to compare with Clang earlier on as I
was suspicious of one of the functions being inlined to blame, just didn't
remove it later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113898
--- Comment #2 from Richard Biener ---
[local count: 101363582]:
# RANGE [irange] int [1, 2]
h_24 = 1;
ivtmp_25 = 1;
e[h_24][_9] = c.5_10;
so there's a missed CCP (this is late FRE). We massaged it to e[1][1] but
it should have been e[1][0] i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113900
Bug ID: 113900
Summary: [14 regression] Hang and then ICe in
vect_transform_loops, at tree-vectorizer.cc:1031 when
building slang-2.3.3
Product: gcc
Version: 14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #13 from Jan Hubicka ---
So my understanding is that ivopts does something like
offset = &base2 - &base1
and then translate
val = base2[i]
to
val = *((base1+i)+offset)
Where (base1+i) is then an iv variable.
I wonder if we con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113900
--- Comment #1 from Sam James ---
Created attachment 57405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57405&action=edit
slarith.i.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113900
--- Comment #2 from Sam James ---
This actually takes ages even when it doesn't ICE:
```
$ gcc -c ./slarith.i -O2 -ftime-report
Time variable usr sys wall
GGC
phase setup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113900
--- Comment #3 from Sam James ---
OK, it takes ages (at least with checking, can't check without right now) with
10/11/12/13/14, so that part isn't a regression. Weird how I didn't notice
before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #14 from rguenther at suse dot de ---
On Tue, 13 Feb 2024, hubicka at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
>
> --- Comment #13 from Jan Hubicka ---
> So my understanding is that ivopts does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113900
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113901
Bug ID: 113901
Summary: [14 regression] ICE when building nodejs-20.11.0
(crash in find_uses_to_rename_use)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
Upstream pull request posted: https://github.com/llvm/llvm-project/pull/81588
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113901
--- Comment #1 from Sam James ---
```
# g++ -c v8_base_without_compiler.regexp-compiler.ii -march=znver2 -O3 -wrapper
valgrind
==21117== Memcheck, a memory error detector
==21117== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113902
Bug ID: 113902
Summary: ice in find_uses_to_rename_use
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113901
Sam James changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
--- Comment #4 from Richard Biener ---
_1 = a[b.1_14][7];
we "correctly" resolve b.1_14 to 1 based on range info which is
[-INF,-1] [1, +INF]. The thing is, the get_ref_base_and_extent code
cannot do anything with this range but adjusting max_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855
--- Comment #7 from Jakub Jelinek ---
I think we should keep this open until the -mx32 stuff is resolved, then it can
be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93814
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
--- Comment #5 from Richard Biener ---
For the first testcase the issue is bitfields and 'off' being tracked in bytes.
ao_ref_init_from_vn_reference handles this by not using 'off'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113600
Filip Kastl changed:
What|Removed |Added
CC||pheeck at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112879
Filip Kastl changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 112879, which changed state.
Bug 112879 Summary: [14 Regression] 4% exec time regression of 525.x264_r on
AMD Zen4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112879
What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112879
Filip Kastl changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #4 from Filip Kastl ---
Thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113900
--- Comment #4 from Sam James ---
I'll bisect and then also try reduce if it has tolerable speed without
checking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113902
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113900
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-02-13
Keywords|compile-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706
Rainer Orth changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113902
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=113901
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113903
Bug ID: 113903
Summary: sched1 should schedule across EBBS
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
--- Comment #6 from Tobias Burnus ---
Created attachment 57407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57407&action=edit
C testcase – passes with patch (except for '#if 0'ed PR113867 issues)
DejaGNU-ified testcase for this PR and (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113901
Richard Biener changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113902
--- Comment #3 from Richard Biener ---
*** Bug 113901 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113891
--- Comment #4 from Steffen ---
I'm not sure how to get this done.
I tried it with -Wl,--no-as-needed, which aborts as well and
-Wl,--whole-archive but that does not compile with undefined reference errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867
--- Comment #4 from Tobias Burnus ---
Also not handled:
struct s { int *p; } s1;
...
#pragma omp target map(s1.p[:N])
p[0] = p[N-1] = 99;
Here, the pointer attachment is missing. See also PR113724 's attachment 57407
for a testcase f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113898
--- Comment #3 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:af6d8d0cc1ac56eba55ef658c664236208f88169
commit r14-8950-gaf6d8d0cc1ac56eba55ef658c664236208f88169
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113898
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113658
--- Comment #7 from GCC Commits ---
The master branch has been updated by Alex Coplan :
https://gcc.gnu.org/g:0d810b7d133c72b7e62b294ffaaf131560ce2391
commit r14-8951-g0d810b7d133c72b7e62b294ffaaf131560ce2391
Author: Alex Coplan
Date: Wed J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113658
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113900
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #27 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:491e57451df47cda88f658601a92d6d006ae09d7
commit r14-8952-g491e57451df47cda88f658601a92d6d006ae09d7
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113900
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #7 from Jakub Jelinek ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113900
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113903
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904
Bug ID: 113904
Summary: [OpenMP][5.0][5.1] Dynamic context selector
'user={condition(expr)}' not handled
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752
--- Comment #7 from Jakub Jelinek ---
Anyway, I think the testcase is very similar to
char a[256], *c, *g;
int
foo (void)
{
if (__builtin_strlen (c) + __builtin_strlen (g) + 5 > 256)
return 0;
__builtin_sprintf (a, "abcd%s%s", c, g);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113902
--- Comment #4 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:aab45e2bbec340201f8faaccfa24756bc09cb7db
commit r14-8953-gaab45e2bbec340201f8faaccfa24756bc09cb7db
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113902
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113900
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113902
--- Comment #6 from Richard Biener ---
*** Bug 113900 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113905
Bug ID: 113905
Summary: [OpenMP] Declare variant rejects variant-function
re-usage
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openmp, rejects-val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113831
--- Comment #8 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:743577e36de66a082d329f71877789599f3ee3b5
commit r14-8954-g743577e36de66a082d329f71877789599f3ee3b5
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113906
Bug ID: 113906
Summary: [OpenMP][5.2] 'construct' context selectors lack many
constructs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openmp, rejec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896
--- Comment #4 from Richard Biener ---
I have a bit of a deja-vu here. The SLP permute optimization phase was
rewritten for GCC 13, the following fixes the latent issue for GCC 12:
diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896
--- Comment #5 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:4a1cd5560b9b545eb848eb1d1e06d345fb606f76
commit r14-8957-g4a1cd5560b9b545eb848eb1d1e06d345fb606f76
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
--- Comment #6 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:94225dfb5623725fa519eac69338f7a632a509ae
commit r14-8956-g94225dfb5623725fa519eac69338f7a632a509ae
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
--- Comment #7 from Richard Biener ---
The issue for the comment#2 testcase remains.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:8a93dc34e90cd8e2bb073f8fd48f671aea62d965
commit r13-8323-g8a93dc34e90cd8e2bb073f8fd48f671aea62d965
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Bug ID: 113907
Summary: [14 regression] ICU miscompiled since on x86 since
r14-5109-ga291237b628f41
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #1 from Sam James ---
I will do the usual bisection of objects and also narrow it down with pragmas.
I won't be able to get much further than that though, I suspect.
-fsanitize=address,undefined builds fine (i.e. it doesn't even seg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #2 from Sam James ---
Program received signal SIGSEGV, Segmentation fault.
0xf770e5c0 in memcpy (__dest=, __src=,
__len=) at /usr/include/bits/string_fortified.h:29
29return __builtin___memcpy_chk (__dest, __src, __len,
(gdb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
Filip Kastl changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #3 from Filip Kastl ---
Btw, the slowdown seems specific to PGO+LTO, with PGO or LTO by itself the
benchmarks execution times are relatively stable:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=991.60.0&plot.1=992.60.0&pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113903
--- Comment #2 from Tamar Christina ---
(In reply to Alexander Monakov from comment #1)
> Lifting those insns from the L8 BB to the L10 BB requires duplicating them
> on all incoming edges targeting L8, doesn't it?
>
No, because they're unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #4 from Robin Dapp ---
Judging by the graph it looks like it was slow before, then got faster and now
slower again. Is there some more info on why it got faster in the first place?
Did the patch reverse something or is it rather a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113908
Bug ID: 113908
Summary: [14 Regression] bogus access error with new-expr of
current non-template class with implicitly deleted
copy ctor
Product: gcc
Version: 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112436
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:ecc119effe1aa445cb973c8cbb5ef3830f256f13
commit r14-8958-gecc119effe1aa445cb973c8cbb5ef3830f256f13
Author: Marek Polacek
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113908
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112436
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113908
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #4 from Sam James ---
Created attachment 57409
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57409&action=edit
udataswp.ii.xz
It goes wrong in common/udataswp.cpp's uprv_copyArray16 and uprv_copyArray64.
(Seemingly both of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #5 from Sam James ---
Created attachment 57410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57410&action=edit
udataswp.cpp.262r.expand (good)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #6 from Sam James ---
Created attachment 57411
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57411&action=edit
udataswp.cpp.262r.expand (bad)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #7 from Sam James ---
Created attachment 57412
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57412&action=edit
udataswp.o (good, r14-5108-g751fc7bcdcdf25)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #8 from Sam James ---
Created attachment 57413
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57413&action=edit
udataswp.o (bad, r14-5109-ga291237b628f41)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #9 from Sam James ---
(In reply to Sam James from comment #4)
> Created attachment 57409 [details]
> udataswp.ii.xz
>
> It goes wrong in common/udataswp.cpp's uprv_copyArray16 and uprv_copyArray64.
>
ah, uprv_copyArray64 -> uprv_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113909
Bug ID: 113909
Summary: gcc.target/i386/pr113689-1.c etc. FAIL
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113909
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #5 from Filip Kastl ---
(In reply to Robin Dapp from comment #4)
> Judging by the graph it looks like it was slow before, then got faster and
> now slower again. Is there some more info on why it got faster in the first
> place? Di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #10 from Jakub Jelinek ---
g++ command line for that TU?
-O2 -march=i686 -std=c++14 -m32
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #11 from Andrew Pinski ---
Does -fwrapv help?
If so does -fsanitize=undefined say anything?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #12 from Sam James ---
-O2 -march=i686 -std=c++11 -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #13 from Sam James ---
(In reply to Andrew Pinski from comment #11)
> Does -fwrapv help?
no (and ubsan suppresses the crash, everything works fine w/ no ubsan output)
--enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240213 (experimental) (GCC)
[520] %
[520] % gcctk -O1 small.c
during GIMPLE pass: fre
small.c: In function ‘main’:
small.c:8:1: internal compiler error: in copy_reference_ops_from_ref, at
tree-ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #14 from Jakub Jelinek ---
There are significant differences in the ranges starting with evrp.
Even optimized has:
--- pr113907.ii.261t.optimized_ 2024-02-13 09:52:13.090609512 -0500
+++ pr113907.ii.261t.optimized 2024-02-13 09:53:3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #15 from Andrew Pinski ---
Note the range part looks correct when taking the mask into account so I am
suspecting the mask is messed up. Let me see if I could spot it later today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #16 from Sam James ---
(In reply to Jakub Jelinek from comment #14
> So it certainly doesn't surprise me some length < 8 check is optimized away
> given the above range info. The question is if it is correct and what
> values the le
1 - 100 of 185 matches
Mail list logo
