https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318
Martin Jambor changed:
What|Removed |Added
Summary|[12/13/14 Regression] |[12 Regression] csmith:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107769
Martin Jambor changed:
What|Removed |Added
Summary|[12/13/14 Regression] -flto |[12 Regression] -flto with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
--- Comment #12 from Martin Jambor ---
My understanding of comment #2 and #3 is that we end up with what are very
likely bogus BB counts that we should check and perhaps attempt to fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109607
--- Comment #3 from Martin Jambor ---
(In reply to Richard Biener from comment #0)
> On cfghooks.cc we replace
>
> BIT_FIELD_REF <*this_8(D), 8, 56>
>
An alternative (perhaps for the release branches) would be to avoid SRA if the
parameter ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107769
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108040
--- Comment #1 from Martin Jambor ---
It is probably me not being able to build the necessary cross compiler
properly, but I cannot build the provided testcase, I always get errors like
the following and then some more:
: note: initializing a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109759
Bug ID: 109759
Summary: UBSAN error: shift exponent 64 is too large for 64-bit
type 'long unsigned int'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109759
--- Comment #2 from Martin Jambor ---
Likely a duplicate of PR 109788.
I'll close the bug as such if it does not manifest itself over the weekend
ubsan bootstrap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109796
Bug ID: 109796
Summary: 548.exchange2_r compiled with -O2 -flto regressed by
5% on aarch64 between r14-135-gd06e9264b0192c and
r14-192-g636e2273aec555
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
Bug ID: 109797
Summary: 456.hmmer compiled with -O2 -flto regressed by 15% on
AMD zen3 between r14-487-g6f18f344338b37 and
r14-540-gb7fe38c14e5f1b
Product: gcc
V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
Martin Jambor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109809
Bug ID: 109809
Summary: ICE in dwarf2out_frame_debug_cfa_offset, at
dwarf2cfi.cc:1376
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106887
--- Comment #4 from Martin Jambor ---
I believe this has been fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109813
Bug ID: 109813
Summary: ICE in in extract_insn, at recog.cc:2791 on ARM with
-mflip-thumb
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
--- Comment #8 from Martin Jambor ---
(In reply to Uroš Bizjak from comment #7)
>
> Martin, does this patch fix the runtime regression?
No, unfortunately it does not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
--- Comment #10 from Martin Jambor ---
The patch from comment #9 does fix the regression. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825
Bug ID: 109825
Summary: [14 Regression] ICE in ix86_widen_mult_cost, at
config/i386/i386.cc:20442 since
r14-666-g608e7f3ab47fe7
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109759
Martin Jambor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788
--- Comment #13 from Martin Jambor ---
*** Bug 109759 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 109759, which changed state.
Bug 109759 Summary: UBSAN error: shift exponent 64 is too large for 64-bit type
'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109759
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
Bug ID: 109886
Summary: UBSAN error: shift exponent 64 is too large for 64-bit
type when compiling gcc.c-torture/compile/pr96796.c
Product: gcc
Version: 14.0
Status: UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
--- Comment #4 from Martin Jambor ---
I don't seem to be able to get riscv64 qemu running in reasonable
time. Can someone please verify that the following patch fixes
the issue?
diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571
Martin Jambor changed:
What|Removed |Added
Summary|[13/14 Regression] ICE in |[13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #71 from Martin Jambor ---
I have sent the patch to the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6le5s25kl@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #24 from Martin Jambor ---
(In reply to Jan Hubicka from comment #23)
> I however wonder if we really guarantee to copy the paddings everywhere else
> then the total scalarization part?
> (i.e. in all paths through the RTL expansion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
--- Comment #7 from Martin Jambor ---
Thanks, I will bootstrap and test the patch on x86_64 and submit it
for review then.
Can I ask you, can you please modify the testcase so that it does not
use printf but simply calls __builtin_abort in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964
--- Comment #4 from Martin Jambor ---
Oops. I made a mistake, the commit above fixes PR 114247, sorry :-/
This one is the next in my queue. Sorry again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
--- Comment #9 from Martin Jambor ---
On master this has been fixed by r14-9813-g8cd0d29270d4ed where I
unfortunately copy-pasted a wrong bug number :-/
I assume this needs backporting to at least gcc-13 and gcc-12. I'll do
that in a week or tw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #26 from Martin Jambor ---
This should be fixed on master, I'll backport the fix in a few weeks to at
least gcc-13 where it was reported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #75 from Martin Jambor ---
The above fixes the testcase from comment #58. I am not sure if any other
testcases discussed here remain unresolved. I am also not sure to what extent
we want to that patch of mine, I guess I'll re-visit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114662
--- Comment #5 from Martin Jambor ---
Thanks a lot for taking care of it before I had a chance to.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
--- Comment #6 from Martin Jambor ---
(In reply to Paweł Bylica from comment #5)
> (In reply to Martin Jambor from comment #4)
> > In this testcase all (well, both) functions referenced from the array
> > are semantically equivalent which is rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964
--- Comment #5 from Martin Jambor ---
(In reply to Richard Biener from comment #2)
> No, I think the issue is that ESRA leaves e.f0 alone:
>
> e$f3_7 = e.f3;
> e$f0$f4_8 = e.f0.f4;
> _1 = e$f0$f4_8;
> _2 = (unsigned char) _1;
> e$f3_9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102310
Martin Jambor changed:
What|Removed |Added
Known to work||13.1.0
Summary|[11/12/13/14/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106935
--- Comment #3 from Martin Jambor ---
This ICE no longer happens with GCC 13, in fact after r13-4240-gfeeb0d68f1c708
(Martin Jambor: ipa-cp: Do not consider useless aggregate constants). From the
patch description, it does not look to be a fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107021
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114935
Bug ID: 114935
Summary: Miscompilation of initializer_list in
presence of exceptions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106935
Martin Jambor changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #16 from Martin Jambor ---
I'll have look, hopefully on Monday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #19 from Martin Jambor ---
The following minimized testcase ICEs with r15-312-g36e877996936ab
cross-compiler to ppc64le with -O2 nicely:
void omp_clause_elt_check(int *, const char *, const char *);
enum { C_OMP_CLAUSE_SPLIT_COUNT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #29 from Martin Jambor ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #20 from Martin Jambor ---
The IL we generate the jump function from is:
_1 = cclauses_2(D) != 0B;
c_parser_omp_all_clauses (_1);
Which translates to the expected jump function:
callsite void c_parser_omp_teams(int**)/3 ->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #32 from Martin Jambor ---
(In reply to Marc Poulhiès from comment #31)
> Hello Martin,
>
> Any chance the fix that fixes the new test for 32bits can be also backported?
>
> 4923ed49b93352bcf9e43cafac38345e4a54c3f8
> https://gcc.gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115174
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
--- Comment #2 from Martin Jambor ---
(In reply to Jan Hubicka from comment #1)
> Reproduces on 14 and trunk. GCC 12 is not able to determine the loop bound
> during early optimizations
What about gcc 13?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115310
Bug ID: 115310
Summary: Option -Werror=return-type is too aggressive with
-std=gnu89
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115310
--- Comment #4 from Martin Jambor ---
(In reply to Sam James from comment #2)
> In such environments, you don't need an explicit
> -Werror=return-type.
I agree I don't need it but it is there.
> So, you're asking presumably about testing with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115329
Bug ID: 115329
Summary: [15 Regression] ICE in extract_insn, at recog.cc:2812
since r15-930-ge715204f203d31
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
Martin Jambor changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112299
Bug ID: 112299
Summary: Cross compiling to loongarch64-linux-gnuf64 fails
because "HAVE_AS_TLS was not declared" after
r14-4925-g1b30ef7cea773e
Product: gcc
Vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112300
Bug ID: 112300
Summary: Cross compiling to mipsisa64r2-sde-elf fails because
"HEAP_TRAMPOLINES_INIT was not declared in this scope"
since r14-4821-g28d8c680aaea46
Product:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 57, which changed state.
Bug 57 Summary: [14 Regression] 416.gamess fails with a run-time abort when
compiled with -O2 -flto after r14-3226-gd073e2d75d9ed4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111878
--- Comment #4 from Martin Jambor ---
I am not 100% certain if it is the same bug (I am happy to open a separate bug
report if not), but I'm getting an ICE on the same spot, also with graphite,
when running
gfortran ~/gcc/trunk/src/libgomp/test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111572
--- Comment #6 from Martin Jambor ---
(In reply to Andrew Pinski from comment #5)
> Hmm, this works on the trunk now. Would be a good idea to figure out what
> "fixed" it.
If my simple test is correct, the error disappeared with
r14-4790-g96923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110302
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 110302, which changed state.
Bug 110302 Summary: libquantum regression on zen3 with LTO and PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110302
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111844
--- Comment #3 from Martin Jambor ---
(In reply to Richard Biener from comment #2)
> It seems to me this is a task for SRA (again...) which should be more
> forgiving to select stmts requiring address-taking of locals but only
> when they are n
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=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=112711
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112721
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
Last recon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112721
--- Comment #2 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638318.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112711
--- Comment #6 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638318.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #27 from Martin Jambor ---
(In reply to Jonathan Wakely from comment #26)
> (In reply to GCC Commits from comment #23)
> > https://gcc.gnu.org/g:aae723d360ca26cd9fd0b039fb0a616bd0eae363
> >
> > commit r14-5831-gaae723d360ca26cd9fd0b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
--- Comment #6 from Martin Jambor ---
Created attachment 56719
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56719&action=edit
Perf annotate of milc built with r14-4971-g0beb1611754742
commit r14-4971-g0beb1611754742:
$ perf stat taskse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
--- Comment #7 from Martin Jambor ---
Created attachment 56720
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56720&action=edit
Perf annotate of milc built with r14-4972-g8aa47713701b1f
commit r14-4972-g8aa47713701b1f:
$ perf stat taskse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112721
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112711
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
--- Comment #22 from Martin Jambor ---
Just to clarify, the case where this causes us problems is (indeed on Aarch64)
with option -fpatchable-function-entry (and NOT necessarily -flive-patching).
But I agree that a separate orthogonal option for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112922
Bug ID: 112922
Summary: 465.tonto from SPECFP 2006 fails train run on
Aarch64-linux with -O2 and -flto
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109932
Bug ID: 109932
Summary: ICE in in extract_insn, at recog.cc:2791 on ppc64le
with -mno-vsx
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #5 from Martin Jambor ---
(In reply to Aldy Hernandez from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Aldy Hernandez from comment #2)
> > > If irange::supports_p (TREE_TYPE (arg)) is true, we're talkin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109987
Bug ID: 109987
Summary: ICE in in rs6000_emit_le_vsx_store on ppc64le with
-Ofast -mno-power8-vector
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110021
Bug ID: 110021
Summary: [14 Regression] ICE in extract_insn, at recog.cc:2791
on x86_64 with -mavx512vl since
r14-1253-g0368fc54bc11f1
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68930
--- Comment #9 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619969.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92497
--- Comment #3 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619969.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106887
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812
--- Comment #14 from Martin Jambor ---
(In reply to Jan Hubicka from comment #13)
> The only difference between slp vectorization is:
>
> - # _68 = PHI <_5(3)>
> - # _67 = PHI <_11(3)>
> - # _66 = PHI <_16(3)>
> - .r = _68;
> - .g = _67;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812
--- Comment #15 from Martin Jambor ---
Oh, because I missed the -DOPACITY in the second command line. The reason for
SRAs creating the repalcement is total scalarization :-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110038
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110038
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #7 from Martin Jambor ---
I see, thanks! But I wonder whether it would make sense to commit the simple
fix in the meantime so that the test pass. It is easy to miss new regressions
now when I expect the overall result not to be cle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110183
Bug ID: 110183
Summary: ICE in extract_constrain_insn, at recog.cc:2692 on
s390x-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #9 from Martin Jambor ---
A buildbot run which checked out this revision unfortunately still reports this
problem with UBSAN-bootstrapped compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 109886, which changed state.
Bug 109886 Summary: UBSAN error: shift exponent 64 is too large for 64-bit type
when compiling gcc.c-torture/compile/pr96796.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104024
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110276
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110276
--- Comment #3 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622019.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110433
Bug ID: 110433
Summary: ASAN reports mismatching new/delete when compiling
analyzer testcases
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110435
Bug ID: 110435
Summary: ICE in in convert_move, at expr.cc:297 on Aarch64 with
-Ofast
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110436
Bug ID: 110436
Summary: ICE in vectorizable_live_operation, at
tree-vect-loop.cc:10170
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110276
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
401 - 500 of 706 matches
Mail list logo
