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
Tamar Christina changed:
What|Removed |Added
Status|NEW |ASSIGNED
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=103311
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
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=103330
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
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
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=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 #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
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=103311
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
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=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=103311
Tamar Christina changed:
What|Removed |Added
Status|NEW |ASSIGNED
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=103305
--- Comment #7 from Tamar Christina ---
Thanks Jakub! I'll apply the changes and do a regtest.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
--- Comment #4 from Tamar Christina ---
Looks like that commit moved the short named to ctype_.h instead of ctype.h.
I'm however unsure if this is something GCC needs to adapt to or if newlib
needs to fix this. They claim it now matches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
--- Comment #3 from Tamar Christina ---
logs indicate that this started happening between
3ba1bd0d9dbc..2ec453b566ac on Nov 12. However that range contains a suspicious
newlib commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #14 from Tamar Christina ---
(In reply to Aldy Hernandez from comment #12)
> (In reply to Tamar Christina from comment #9)
> > (In reply to Aldy Hernandez from comment #8)
> > > (In reply to Tamar Christina from comment #7)
> > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #5 from Tamar Christina ---
(In reply to Aldy Hernandez from comment #4)
> Is this still an issue with the latest trunk? There have been a few changes
> in this space (phi ordering, loop header copying, etc).
At least on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #9 from Tamar Christina ---
(In reply to Aldy Hernandez from comment #8)
> (In reply to Tamar Christina from comment #7)
> > Just a note, in our case the error seems to cause stage2 build to fail.
>
> Please file a PR for it and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
Bug ID: 103305
Summary: [12 Regression] Cannot build aarch64-none-elf
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: build, wrong-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
Tamar Christina changed:
What|Removed |Added
Host|powerpc64le-linux-gnu |powerpc64le-linux-gnu,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #7 from Tamar Christina ---
Just a note, in our case the error seems to cause stage2 build to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103169
Tamar Christina changed:
What|Removed |Added
Status|NEW |ASSIGNED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103253
--- Comment #9 from Tamar Christina ---
> We might want to eventually special-case some of the internal fns
> in internal_fn_flags? Or have a special ECF_FP_TRAP which
> we'd rewrite in internal_fn_flags based on flag_trapping_math
> (but we'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103253
--- Comment #7 from Tamar Christina ---
> .COND_MUL might raise an exception and DCE removes unused LHS of calls.
> Looks like FMA analysis doesn't like internal fns w/o a LHS?
That makes sense, it looks like it needs the LHS to find the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103253
--- Comment #5 from Tamar Christina ---
Looks like the RPO pass is causing match.pd to simply
vect_iftmp.10_41 = vect__1.9_38 * vect_cst__40;
vect_iftmp.10_42 = vect__1.9_39 * vect_cst__40;
iftmp.0_8 = _1 * 2.0e+0;
mask_patt_19.11_44 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103253
Tamar Christina changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95962
--- Comment #3 from Tamar Christina ---
This is now fixed on trunk, at least for ld1/st1.
Was this ticket about the general problem for loads or just the ld1/st1
examples?
I'll leave it open since we still need to do the rest of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103196
--- Comment #1 from Tamar Christina ---
I'm not an expert on the Power ISA either, but it kinda looks like that code
was unrolled.
The change is supposed to CSE redundant instructions early so perhaps it now
fits into your default rtl unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103042
Tamar Christina changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103169
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=103042
--- Comment #7 from Tamar Christina ---
> gcc/testsuite/gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-double.c
This one running is odd, it's guarded by vect_double which doesn't match
sparc-*-*-*. That should be unresolved now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103094
--- Comment #3 from Tamar Christina ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Tamar Christina from comment #1)
> > Looks like it's wrong from expand already, it's expanding into overlapping
> > registers.
>
> Maybe a dup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103094
--- Comment #1 from Tamar Christina ---
Looks like it's wrong from expand already, it's expanding into overlapping
registers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103094
Tamar Christina changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103094
Bug ID: 103094
Summary: [12 Regression] Incorrect codegen from AArch64
intrinsics
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103042
--- Comment #6 from Tamar Christina ---
ok, then I don't think sparc can vectorize these cases at all through SLP, so I
will just skip them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103085
Bug ID: 103085
Summary: [12 Regression] -fPIC and -fstack-protector-strong
broken AArch64
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103042
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103042
Tamar Christina changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 103007, which changed state.
Bug 103007 Summary: [12 Regression] ice in vect_normalize_conj_loc, at
tree-vect-slp-patterns.c:722 since
r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103042
--- Comment #2 from Tamar Christina ---
Thanks, yeah, SLP discovery failed for all of them.
I think I should just unroll all these.
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=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=103007
Tamar Christina changed:
What|Removed |Added
Status|NEW |ASSIGNED
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=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
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=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
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=102907
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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
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
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=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:
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
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||tnfchris at gcc dot gnu.org
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=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
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=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
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877
Tamar Christina changed:
What|Removed |Added
Version|11.0|12.0
--- Comment #5 from Tamar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197
--- Comment #18 from Tamar Christina ---
(In reply to Martin Liška from comment #17)
> Waiting for Tamara's test-case now.
> Btw. can you please share a pointer to the Github repsitory?
Sure, it's this project and this particular call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197
--- Comment #13 from Tamar Christina ---
(In reply to cqwrteur from comment #12)
> (In reply to cqwrteur from comment #11)
> > (In reply to Tamar Christina from comment #10)
> > > (In reply to cqwrteur from comment #9)
> > > > (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197
--- Comment #10 from Tamar Christina ---
(In reply to cqwrteur from comment #9)
> (In reply to Tamar Christina from comment #8)
> > (In reply to Jakub Jelinek from comment #6)
> > > Shouldn't that be a different PR with details? I mean, this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197
--- Comment #8 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #6)
> Shouldn't that be a different PR with details? I mean, this PR is that we
> should expand shorter memmove inline even if the regions do overlap.
Sure, I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197
Tamar Christina changed:
What|Removed |Added
Build|x86_64-linux-gnu|x86_64-linux-gnu,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877
Bug 98877 depends on bug 91753, which changed state.
Bug 91753 Summary: Bad register allocation of multi-register types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958
Bug 95958 depends on bug 91753, which changed state.
Bug 91753 Summary: Bad register allocation of multi-register types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47562
Bug 47562 depends on bug 91753, which changed state.
Bug 91753 Summary: Bad register allocation of multi-register types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95962
Tamar Christina changed:
What|Removed |Added
Last reconfirmed||2021-08-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95964
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91598
--- Comment #13 from Tamar Christina ---
(In reply to Maxim Kuvyrkov from comment #12)
> (In reply to Tamar Christina from comment #11)
> > Can this issue be closed? all inline assembly have been removed from
> > arm_neon.h but backporting these
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95967
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91598
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101842
--- Comment #5 from Tamar Christina ---
(In reply to Richard Biener from comment #4)
> (In reply to Tamar Christina from comment #3)
> > (In reply to Richard Biener from comment #2)
> > > OK, so with a hack like the following we vectorize the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101842
--- Comment #3 from Tamar Christina ---
(In reply to Richard Biener from comment #2)
> OK, so with a hack like the following we vectorize the BB as
>
> vect__1.10_62 = MEM [(float *)p_34];
> vect_powmult_9.11_61 = vect__1.10_62 *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101842
Bug ID: 101842
Summary: Vectorizer doesn't vectorize when loop bound depends
on two independent variables that are unknown
Product: gcc
Version: 12.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #7 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #6)
> On Wed, 4 Aug 2021, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
> >
> > --- Comment #5 from Tamar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #5 from Tamar Christina ---
And yes the same semantics apply to 'i', but if I read it right the patch in
r12-2523 is tracking variables that are read but never written to. So 'i'
escaped the same issue because it's written to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #4 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #3)
> On Tue, 3 Aug 2021, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
> >
> > --- Comment #2 from Tamar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> On x86_64 the testcase is optimized to the following now:
> not sure how we conclude that 'n' is not written to anywhere. The issue
> persists even when I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101553
--- Comment #2 from Tamar Christina ---
Thanks, I didn't see the patch, I've pinged the maintainers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101553
Tamar Christina changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101553
Bug ID: 101553
Summary: [12 Regression] armhf builds broken on
-Werror=array-bounds
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92538
Tamar Christina changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101457
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101457
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=101372
--- Comment #2 from Tamar Christina ---
yes revering r12-2132 does indeed fix it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101372
Bug ID: 101372
Summary: [12 Regression] Bootstrap failure compiling
gcc/cp/module.cc
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
601 - 700 of 768 matches
Mail list logo
