https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103253
--- Comment #12 from Tamar Christina ---
Fixed the ice on trunk, the issue with the IFN still need to be addressed.
Unsure whether to reclassify this ticket or make a new one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103311
Tamar Christina changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
--- Comment #8 from Tamar Christina ---
This seems to work, would you like me to submit the patch or will you do it
Jakup?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
--- Comment #10 from Tamar Christina ---
Oh yes, sorry, I kept saying the wrong name :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #8 from Tamar Christina ---
(In reply to Aldy Hernandez from comment #7)
> Could someone post the relevant configury bits used for the ppc64le case.
>
> I used:
>
> runcpu --config=myconfig -a validate --iterations=1 --ignore-erro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103311
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103311
Tamar Christina changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #11 from Tamar Christina ---
> > Richi the configury bits you shared once upon a time had
> > -fno-unsafe-math-optimizations for 500.perlbench. Are there known issues
> > with
> > this test for -ffast-math that we had -fno-unsafe-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
--- Comment #12 from Tamar Christina ---
Fixed on master, is this something we'd want to backport to active branches?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #16 from Tamar Christina ---
(In reply to Martin Liška from comment #14)
> > > Richi the configury bits you shared once upon a time had
> > > -fno-unsafe-math-optimizations for 500.perlbench. Are there known issues
> > > with
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #18 from Tamar Christina ---
(In reply to Martin Liška from comment #17)
> > I don't mind closing this as invalid, however this isn't a known limitation,
> > it's a new limitation.
>
> Yes, it may be a new limitation or we may be af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103330
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103330
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103311
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #23 from Tamar Christina ---
Thanks Aldy!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103404
Tamar Christina changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103417
--- Comment #5 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 51870 [details]
> gcc12-pr103417.patch
>
> Untested fix. Handling GE in that simplification is clearly bogus, we
> should just fold it to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103404
--- Comment #5 from Tamar Christina ---
This is a somewhat latent bug in CSE where merge_equiv_classes assumes that all
entries into the equivalence table are unique but CSE makes no attempt to
enforce this constraint.
So inserting the same equ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #8 from Tamar Christina ---
>
> I wonder how the situation looks on AArch64?
The situation didn't improve, up until the end of stage-1 we were seeing a 6%
perf uplift from somewhere which seems to have gone away now (in a commit ran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103479
--- Comment #1 from Tamar Christina ---
Could you post the dce7 dump file if you have it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
--- Comment #20 from Tamar Christina ---
Newlib ML thread https://sourceware.org/pipermail/newlib/2021/018706.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103479
--- Comment #3 from Tamar Christina ---
(In reply to seurer from comment #2)
> Created attachment 51907 [details]
> dec7 dump file
>
> Dump file attached
Got it, thanks, I'll fix it today, the regexp is too liberal in this case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103523
Bug ID: 103523
Summary: [12 Regression] SVE float auto-vect float format
expand failure
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103523
--- Comment #1 from Tamar Christina ---
An additional ICE seen on a month old tree is
during GIMPLE pass: veclower2
zbuf.i: In function 'd':
zbuf.i:3:1: internal compiler error: in to_constant, at poly-int.h:504
0xbc9494 poly_int_pod<2u, unsign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103479
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103547
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103547
Tamar Christina changed:
What|Removed |Added
CC|tamar.christina at arm dot com |
--- Comment #2 from Tamar Chr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
--- Comment #22 from Tamar Christina ---
Ok, great, Jonathan what do you want to do, do we need to revert the commit or
just close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103404
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103523
--- Comment #6 from Tamar Christina ---
Looks like the ICE is cause by a bug in `vectorizable_induction` not checking
for MULT_EXPR and PLUS_EXPR for the given type before it tries to emit them.
This then leads to veclower trying to lower the o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #11 from Tamar Christina ---
(In reply to Jan Hubicka from comment #10)
> Thanks for looking into this. I was planning to try to contact Vladimir
> about the IRA behaviour here, but there was always something else to work
> with highe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #12 from Tamar Christina ---
Created attachment 51942
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51942&action=edit
0001-PATCH-1-2-GCC-reload-Weigh-available-callee-saves-ba.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #13 from Tamar Christina ---
Created attachment 51943
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51943&action=edit
0002-PATCH-2-2-GCC-reload-Don-t-move-if-the-next-BB-has-m.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #15 from Tamar Christina ---
> That is, we're trading two memory accesses in the call branch
> (if we allocate R) against one memory access in both branches
> (if we spill R). As the call branch gets more likely,
> the cost of doing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #17 from Tamar Christina ---
> On “CALL_FREQ grows much quicker than BB_FREQ”: for r104, the
> ALLOCNO_FREQ ought in principle to be fixed for a given loop iteration
> count. It shouldn't grow or shrink based on the value of SPILLED.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103523
Tamar Christina changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103253
Tamar Christina changed:
What|Removed |Added
Priority|P1 |P3
Summary|[12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103632
Tamar Christina changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103350
--- Comment #5 from Tamar Christina ---
*** Bug 103632 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103350
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103094
Tamar Christina changed:
What|Removed |Added
CC||jonathan.wright at arm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #23 from Tamar Christina ---
(In reply to Jan Hubicka from comment #20)
> With g:r12-5872-gf157c5362b4844f7676cae2aba81a4cf75bd68d5 we should no
> longer need -fno-inline-functions-called-once
Awesome! thanks!
I wonder if we can get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #25 from Tamar Christina ---
(In reply to hubicka from comment #24)
> > Awesome! thanks!
> >
> > I wonder if we can get rid of the final magic parameter too, we run with
> > --param ipa-cp-unit-growth=80 too which seems to have no mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #27 from Tamar Christina ---
(In reply to hubicka from comment #26)
> > It's with LTO, I'll see if non-LTO has the same benefit. In terms of
> > code-size
> > it looks like it accounts for a 20% increase for binary size, but the hot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #28 from Tamar Christina ---
(In reply to pthaugen from comment #19)
> I tried -fno-inline-functions-called-once and the patches on a Power9
> system. Following are the run times and spill counts (grep -c Spilling
> exchange2.fppized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103350
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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: i
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=78136
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
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=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
--- 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
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102188
Bug ID: 102188
Summary: Over widening detection doesn't work when no range
information
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102218
Bug ID: 102218
Summary: 128-bit atomic compare and exchange does not honor
memory model on AArch64 and Arm
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102448
Bug ID: 102448
Summary: [12 Regression] wrong codegen in gcc in spec2017 since
24f99147b9264f8f7d9cfb2fa6bd431edfa252d2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102448
--- Comment #2 from Tamar Christina ---
I have double checked the revision and it does start happening with it.
Though I can only reproduce it with -flto. the codegen without lto seems the
same.
Any ideas how to debug further?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102448
--- Comment #8 from Tamar Christina ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
Tamar Christina changed:
What|Removed |Added
CC|tamar.christina at arm dot com |
--- Comment #17 from Tamar Ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102893
Bug ID: 102893
Summary: [8/9/10/11/12 Regression] CDDCE does not detect empty
infinite nested loops
Product: gcc
Version: 8.5.0
Status: UNCONFIRMED
Keywords: m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102171
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102897
Bug ID: 102897
Summary: [12 Regression] simplify_permutation ICEs on assert
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102893
--- Comment #4 from Tamar Christina ---
Thanks for the fix!
This was reported to us by a user of the arm embedded toolchains that was
upgrading from gcc 7. We won't be releasing any new releases for GCC 8 and 9,
but may be for 10 and 11 is cer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102907
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102977
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=102977
--- Comment #8 from Tamar Christina ---
Actually I'll just push the fix for this out now.
> The testcases added for this case does not actually test that complex fma was
> done.
yes, the way we were originally testing depended on target suppo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102977
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103000
--- Comment #2 from Tamar Christina ---
(In reply to Andrew Pinski from comment #1)
> Looks like these are missing { target { vect_complex_add_float } } in there.
>
No, that's not right, `vect_complex_add_float` is for when the target supports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007
--- Comment #4 from Tamar Christina ---
Yes a lane check size is missing from fms, will be fixed in a bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007
Tamar Christina changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007
--- Comment #7 from Tamar Christina ---
Yes, I've posted a patch for this already
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583008.html
waiting review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103000
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430
--- Comment #16 from Tamar Christina ---
I think this can be closed now right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430
Tamar Christina changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46279
Bug 46279 depends on bug 89430, which changed state.
Bug 89430 Summary: A missing ifcvt optimization to generate csel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 89430, which changed state.
Bug 89430 Summary: A missing ifcvt optimization to generate csel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
Bug ID: 107675
Summary: [13 Regression] GCC-13 is significantly slower to
startup on C++ programs
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
--- Comment #1 from Tamar Christina ---
Note that to test this, the glibc version stayed the same.
Also when using the default dynamically linked version, pointing to the GCC-12
libstdc++ from the GCC-13 also has no slowdown. So this seems to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
--- Comment #4 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #2)
> Does the binary and libstdc++.so have PT_GNU_EH_FRAME header including
> binary search table (readelf -Wl | grep GNU_EH_FRAME)?
> During startup I think there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107717
Bug ID: 107717
Summary: [13 Regression] ICEs expanding permutes after
g:dc95e1e9702f2f6367bbc108c8d01169be1b66d2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107717
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=107717
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #11 from Tamar Christina ---
(In reply to Richard Biener from comment #10)
> Tamar, are the IFN_COMPLEX_FMA and IFN_COMPLEX_FMA_CONJ FP contracting
> operations as well?
Yes, they have no intermediate rounding.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #12 from Tamar Christina ---
Note that the same IFN is used for integer MLA as well. We didn't split them
apart.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #14 from Tamar Christina ---
(In reply to Richard Biener from comment #13)
> Created attachment 53917 [details]
> patch I am testing
>
> OK, I'm testing the following then - can you see if that works for the
> complex fmas and if th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
--- Comment #7 from Tamar Christina ---
(In reply to Andrew Pinski from comment #5)
> Can you try right before r13-3707-g4e4e3ffd10f53e and right afterwards?
>
> I would have assumed, the exception would not happen really.
Sadly doesn't seem t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
--- Comment #9 from Tamar Christina ---
(In reply to Florian Weimer from comment #8)
> (In reply to Tamar Christina from comment #4)
> > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-fde.c:111
> > #6 __register_frame_info (begin=, ob=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
--- Comment #10 from Tamar Christina ---
I've bisected this to:
commit 6e80a1d164d1f996ad08a512c25a7c2ca893
Author: Thomas Neumann
Date: Tue Mar 1 21:57:35 2022 +0100
eliminate mutex in fast path of __register_frame
The __regis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
Tamar Christina changed:
What|Removed |Added
Component|libstdc++ |libgcc
--- Comment #11 from Tamar Chr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #19 from Tamar Christina ---
FWIW, the testsuite on AArch64 was clean after the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
Thomas Neumann changed:
What|Removed |Added
CC||tneumann at users dot
sourceforge.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107830
Tamar Christina changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Tamar Ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107830
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107988
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=108070
--- Comment #1 from Tamar Christina ---
Yes it's all been approved now, doing a regression after a rebase and will
commit today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108070
--- Comment #2 from Tamar Christina ---
Committed, implementing the tbranch optab should allow this to be fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107988
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
201 - 300 of 828 matches
Mail list logo