https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> I believe this was some match.pd simplification - why does this affect the
> addressing mode? Is the IVOPTs result different or does it differ later?
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106524
Tamar Christina changed:
What|Removed |Added
Summary|[12/13 Regression] ICE in |[12 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
Bug ID: 106594
Summary: [13 Regression] sign-extensions no longer merged into
addressing mode
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106524
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106553
--- Comment #2 from Tamar Christina ---
(In reply to Alexander Monakov from comment #1)
> Are you sure the testcase is correctly reduced, i.e. does it show the same
> performance degradation? Latency-wise the scheduler is making the correct
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106553
Bug ID: 106553
Summary: pre-register allocation scheduler is now RMW aware
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534
--- Comment #9 from Tamar Christina ---
(In reply to Tamar Christina from comment #6)
> (In reply to rguent...@suse.de from comment #5)
> > On Fri, 5 Aug 2022, burnus at gcc dot gnu.org wrote:
> >
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534
--- Comment #6 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #5)
> On Fri, 5 Aug 2022, burnus at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534
> >
> > --- Comment #4 from Tobias Burnus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534
--- Comment #3 from Tamar Christina ---
Thanks for the repro, could you tell me what target I need to use or what
configure options to build amdgcn-amdhsa?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106519
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106519
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106346
--- Comment #6 from Tamar Christina ---
(In reply to Richard Biener from comment #5)
> (In reply to Tamar Christina from comment #4)
> > I believe the problem is actually g:27842e2a1eb26a7eae80b8efd98fb8c8bd74a68e
> >
> > We added an optab for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106346
Tamar Christina changed:
What|Removed |Added
Summary|Potential regression on |[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106346
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253
--- Comment #10 from Tamar Christina ---
For completeness, I reduced the Armhf failure and that seems to happen on
bswap.
#include
#include
void
__sha256_process_block (uint32_t *buffer, size_t len, uint32_t *W)
{
for (unsigned int t = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106253
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106196
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106196
--- Comment #6 from Tamar Christina ---
(In reply to Richard Biener from comment #5)
> (In reply to Tamar Christina from comment #4)
> > Some benchmarks are still failing with the same error, just different line
> > I am reducing a testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106196
Tamar Christina changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106217
Bug ID: 106217
Summary: [11/12/13 Regression] sinking of loads prevents
vectorization
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106196
Bug ID: 106196
Summary: [13 Regression] vect_do_peeling ICE since
g:3769ad4ccea9589b3f7edaef901cb542aa10f49a
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106137
--- Comment #4 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 53224 [details]
> gcc13-pr106137.patch
>
> Perhaps this patch could fix this?
The patch does fix the build! I also have the 4 files you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106137
--- Comment #3 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #1)
> Could you please attach
> */libgfortran/Makefile
> */libgfortran/config.h
> from the build dir before/after that commit?
Waiting for a build to finish to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106137
Bug ID: 106137
Summary: baremetal cross builds broken in libgfortran since
g:133d0d422ebd18dbd215cfa5394aff9f938e7060
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106106
--- Comment #4 from Tamar Christina ---
>
> Is the fact that float32x2x2_t is an aggregate with a field named 'val'
> part of the neon API?
Yeah, it's mandated by ACLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106106
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> SRA is eliding 'v' by doing what it does, so it essentially changes
> it looks like providing __builtin_neon_vld2_lanev2sf with float32x2x2
> argument and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106106
Bug ID: 106106
Summary: SRA scalarizes structure copies
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106063
--- Comment #4 from Tamar Christina ---
Ah, there's optimize_vectors_before_lowering_p,
would you prefer I check the operation or just gate the pattern on the above
Richi?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106063
--- Comment #3 from Tamar Christina ---
(In reply to Richard Biener from comment #2)
>
> but after vector lowering only vector operations that are handled by the
> target may be introduced. The pattern
>
We can't tell that we're after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105874
--- Comment #8 from Tamar Christina ---
Can confirm that the benchmark works again.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105874
--- Comment #5 from Tamar Christina ---
Ah, great, Thanks Roger!
I did end up reducing it to:
template class b {
public:
int c[a];
int operator[](long d) const { return c[d]; }
};
class board {
bool is_eye(int, int);
static const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105874
--- Comment #3 from Tamar Christina ---
(In reply to Roger Sayle from comment #1)
> Hi Tamar.
> I'm truly sorry for the inconvenience. Can you try reducing again now that
> the load_register_parameters issue with the "small const structs as
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105874
Bug ID: 105874
Summary: [13 Regression] Incorrect codegen and ICE since
g:ed6fd2aed58f2cca99f15331bf68999c0e6df370
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102218
Tamar Christina changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94793
Tamar Christina changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105451
Bug ID: 105451
Summary: miss optimizations due to inconsistency in complex
numbers associativity
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105095
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
Tamar Christina changed:
What|Removed |Added
Assignee|tnfchris at gcc dot gnu.org|avieira at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
--- Comment #10 from Tamar Christina ---
nb_iterations_upper_bound is indeed set incorrectly and tracked to this commit,
commit 7ed1cd9665d8ca0fa07b2483e604c25e704584af
Author: Andre Vieira
Date: Thu Jun 3 13:55:24 2021 +0100
vect: Use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
--- Comment #8 from Tamar Christina ---
looks like the code out of the vectorizer is fine, and between the two versions
it doesn't change.
The big change is in the unroller, decides to drops one of the BBs for some
reason.
It turns the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
--- Comment #7 from Tamar Christina ---
I have managed to find the commit where this starts failing:
commit 61fc5e098e76c9809f35f449a70c9c8d74773d9d (HEAD)
Author: Richard Biener
Date: Fri Feb 18 11:34:52 2022 +0100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
--- Comment #5 from Tamar Christina ---
OK, I think this is an alignment issue.
When using the thunderx cost model it needs to peel the loop for alignment in
order to vectorize and it looks the error is there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
--- Comment #4 from Tamar Christina ---
(In reply to Alex Coplan from comment #3)
> (In reply to Tamar Christina from comment #1)
> > Smaller reproducer getting rid of the loop nest and simplify the inner
> > condition.
>
> Hmm, I can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105197
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105197
Tamar Christina changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105197
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104039
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105196
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104409
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104409
Tamar Christina changed:
What|Removed |Added
Summary|-march=armv8.6-a+ls64 |[12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
Tamar Christina changed:
What|Removed |Added
Target Milestone|12.0|13.0
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105095
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157
--- Comment #7 from Tamar Christina ---
(In reply to Richard Biener from comment #6)
> More to the point the cited rev. doesn't look like it should change anything
> for -mtune=generic. Maybe the "generic" config is always the last one on
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #15 from Tamar Christina ---
(In reply to rsand...@gcc.gnu.org from comment #14)
>
> So IMO we should fix RTL representation problem that Andrew pointed
> out in comment 7 as the P1 fix, then accept the other cases as a P2
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105095
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #13 from Tamar Christina ---
That said, I'll wait for Richard S to respond, but I don't think this is a P1
any longer, we know why it can't be done during reload and neither sequences
are really significantly better/worse.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #12 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #10)
> Could we fix this up in postreload or later?
> (insn 35 18 21 2 (set (reg:SI 0 x0 [125])
> (reg:SI 32 v0 [117])) "pr104049.c":16:33 52
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #11 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #9)
> Perhaps the r12-2288-g8695bf78dad1a42636 change wasn't a good idea?
I think it's still a good idea as it fixes a bigger problem (unneeded SIMD
partial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012
Bug ID: 105012
Summary: [12 Regression] wrf from SPECCPU2017 ICEs during LTO
linking
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104755
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
--- Comment #7 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #6)
> I don't see the code mentioned in #c0 on x86_64, I see also loads and stores
> like on aarch64.
Yes, that was my mistake, I was accidentally comparing GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104755
--- Comment #4 from Tamar Christina ---
Hmmm looks like it doesn't support vector comparisons
missed: not vectorized: relevant stmt not supported: _6 = _5 <= 255;
I'll probably just have to skip them on sparc*-* then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104730
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104755
--- Comment #2 from Tamar Christina ---
Hmmm the tests are gated by vect_int which sparc declares to support but the
code didn't vectorize, so probably an unsupported operation somewhere..
Could you attach the output of -fdump-tree-vect-all?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104730
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
Tamar Christina changed:
What|Removed |Added
Summary|[missed optimization] |[12 Regression] inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
--- Comment #2 from Tamar Christina ---
I don't quite see how this is a CSE problem,
There's only one of each constant and none of them are needed before the call.
unlike in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86892
You don't need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
Bug ID: 104529
Summary: [missed optimization] inefficient codegen around
new/delete
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94294
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
--- Comment #34 from Tamar Christina ---
(In reply to Andrew Pinski from comment #33)
> (In reply to Tamar Christina from comment #32)
> > I'm not sure... I can't seem to get the same granularity level that Andrew
> > got... How did you get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
--- Comment #32 from Tamar Christina ---
>
> I suppose the slowness is still entirely within synth_mult?
I'm not sure... I can't seem to get the same granularity level that Andrew
got... How did you get that report Andrew?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
--- Comment #30 from Tamar Christina ---
No problem during nightlies. No real changes in other workloads in compile time
nor runtime.
can confirm no perf change for xxhash and compile time decreased from 8 to 1
sec.
tree vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104408
--- Comment #4 from Tamar Christina ---
(In reply to Richard Biener from comment #3)
> match.pd just does canonicalization here. SLP discovery could handle this
> in the existing swap operands or reassoc support but I guess the desire here
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104408
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104408
--- Comment #1 from Tamar Christina ---
In particular, the rewrite should probably be gated on the expression being
single use.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104405
--- Comment #4 from Tamar Christina ---
(In reply to Andrew Pinski from comment #2)
> The big question becomes now is really an issue in real world code or just a
> toy benchmark which is testing argument/return passing optimizations?
Can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104406
--- Comment #2 from Tamar Christina ---
Yeah it looks like there's an overlap with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485 indeed, but that ticket
seems to be trying to address multiple things at once including an x86 costing
issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104408
Bug ID: 104408
Summary: SLP discovery fails due to -Ofast rewriting
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104406
Bug ID: 104406
Summary: SLP discovery doesn't use TWO_OPERAND nodes as seeds
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104405
Bug ID: 104405
Summary: Inefficient register allocation on complex arithmetic
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
--- Comment #29 from Tamar Christina ---
(In reply to Richard Biener from comment #28)
> I'm not removing the regression marker yet - can ARM folks please update the
> trunk numbers with a fully built compiler (w/o checking)?
Sure, I'll come
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819
Tamar Christina changed:
What|Removed |Added
Summary|[11/12 Regression] |[11 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103169
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #8 from Tamar Christina ---
(In reply to Andrew Pinski from comment #7)
> Hmm,
> ;; _43 = .REDUC_PLUS (vect__7.11_47);
>
> (insn 23 22 24 (set (reg:V4SI 112)
> (unspec:V4SI [
> (reg:V4SI 103 [ vect__7.11 ])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #4 from Tamar Christina ---
(In reply to Vladimir Makarov from comment #3)
> (In reply to Richard Biener from comment #2)
> > We need to understand the issue at least.
>
> I think that it is not an RA problem.
>
> IRA assigns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
Bug ID: 104049
Summary: [12 Regression] vec_select to subreg lowering causes
superfluous moves
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771
--- Comment #1 from Tamar Christina ---
Looks like the change causes the simpler conditional to be detected by the
vectorizer as a masked operation, which in principle makes sense:
note: vect_recog_mask_conversion_pattern: detected:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103741
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103741
--- Comment #4 from Tamar Christina ---
Patch missing a check on vec_mode, testing a fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103741
--- Comment #2 from Tamar Christina ---
AH!
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x7fdf17594738 precision:64 min max
pointer_to_this >
VNx2DI
size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103741
Tamar Christina changed:
What|Removed |Added
Last reconfirmed||2021-12-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78136
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #30 from Tamar Christina ---
(In reply to Martin Jambor from comment #29)
> (In reply to Tamar Christina from comment #23)
> > I wonder if we can get rid of the final magic parameter too, we run with
> > --param ipa-cp-unit-growth=80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103734
Bug ID: 103734
Summary: IPA-CP opportunity for imagick in SPECCPU 2017
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103350
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
501 - 600 of 797 matches
Mail list logo
