https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #59 from Tamar Christina ---
I've sent two patches upstream this morning to fix the remaining ifcvt issues:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623848.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #33 from Tamar Christina ---
(In reply to Sam James from comment #32)
> I'll tentatively reopen as IIRC tamar mentioned they've had some ideas about
> this, apologies if I'm misremembering.
Hello, yes I have a patch locally that I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110336
Bug ID: 110336
Summary: Ada doesn't build with coverage enabled on Arm
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110329
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110324
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110223
Bug ID: 110223
Summary: Missed optimization vectorizing booleans comparisons
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110142
--- Comment #2 from Tamar Christina ---
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110142
Bug ID: 110142
Summary: [14 Regression] x264 from SPECCPU 2017 miscompares
from g:2f482a07365d9f4a94a56edd13b7f01b8f78b5a0
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109940
Tamar Christina changed:
What|Removed |Added
Known to work|13.1.0 |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711
--- Comment #6 from Tamar Christina ---
my own bisect does indeed end up at r14-377-gc92b8be9b52b7e and cannot
reproduce it on GCC 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711
--- Comment #5 from Tamar Christina ---
(In reply to Martin Liška from comment #3)
> Hm, on x86_64-linux-gnu, it started with r13-6616-g2246d576f922ba.
$ cat prtest2.c
void lspf2lpc();
int interpolate_lpc_q_0;
void
interpolate_lpc(int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #9 from Tamar Christina ---
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #6 from Tamar Christina ---
That's an interesting approach, I think it would also fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109391 would it not? Since the
int16x8x3_t return would be "scalarized" avoiding the bad expansion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #3 from Tamar Christina ---
note that even if we can't stop SLP, we should be able to generate as efficient
code by being creative about the instruction selection, that's why I marked it
as a target bug :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> Well, the usual unknown ABI boundary at function entry/exit.
Yes but LLVM gets it right, so should be a solve able computer science problem.
:)
Note that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
Bug ID: 109632
Summary: Inefficient codegen when complex numbers are emulated
with structs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
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=109154
--- Comment #54 from Tamar Christina ---
@Jakub, just to check to avoid doing duplicate work, did you intend to do the
remaining ifcvt changes or should we?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109587
--- Comment #7 from Tamar Christina ---
(In reply to Richard Biener from comment #5)
> (In reply to Tamar Christina from comment #4)
> > (In reply to Richard Biener from comment #3)
> > > The issue isn't unrolling but invariant motion. We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109587
--- Comment #4 from Tamar Christina ---
(In reply to Richard Biener from comment #3)
> The issue isn't unrolling but invariant motion. We unroll the innermost
> loop, vectorizer the middle loop and then unroll that as well. That leaves
> us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109587
Bug ID: 109587
Summary: Deeply nested loop unrolling overwhelms register
allocator
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #42 from Tamar Christina ---
Thanks for all the work so far folks!
Just to clarify the current state, it looks like the first reduced testcase is
now correct.
But the larger example as in c26 is still suboptimal, but slightly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109391
Bug ID: 109391
Summary: Inefficient codegen on AArch64 when structure types
are returned
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #25 from Tamar Christina ---
Created attachment 54777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54777=edit
extracted codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #24 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Richard Biener from comment #11)
> > _1 shoud be [-Inf, nextafter (0.0, -Inf)], not [-Inf, -0.0]
> The reduced testcase is invalid because it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
--- Comment #11 from Tamar Christina ---
Neither of those vec_perms are valid targets for this optimization.
It looks like sel.series_p is not doing what I expected. It's matching even
elements and ignoring the odd ones.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
--- Comment #1 from Tamar Christina ---
That patch only fixed the bootstrap, in any case I'm on holidays so have asked
someone else to look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
Tamar Christina changed:
What|Removed |Added
Summary|[13 regression] aarch64 |[13 regression] jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #2 from Tamar Christina ---
Confirmed, It looks like the extra range information from
g:4fbe3e6aa74dae5c75a73c46ae6683fdecd1a75d is leading jump threading down the
wrong path.
Reduced testcase:
---
int etot_0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109156
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=109156
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> (In reply to Tamar Christina from comment #0)
> > 2. It looks like all targets that implement SAD do so with an instruction
> > that does ABD and then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #1 from Tamar Christina ---
Thanks for the report, taking a look!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109156
Bug ID: 109156
Summary: Support Absolute Difference detection in GCC
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109153
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=109153
--- Comment #3 from Tamar Christina ---
(In reply to Richard Biener from comment #2)
> On the GIMPLE side we should canonicalize here I think, at which point
> inserts into a splatted vector become more profitable depends?
>
> _4 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109153
Bug ID: 109153
Summary: missed vector constructor optimizations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109130
--- Comment #1 from Tamar Christina ---
I can't reproduce that. on a Neoverse-N1 I see between those two commits:
./bench-compare.sh 2fc55f51f99 bad177e8487
A 1457 files
D 0 files
M 0 files
Extracted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109118
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
--- Comment #4 from Tamar Christina ---
(In reply to rsand...@gcc.gnu.org from comment #3)
> (In reply to Tamar Christina from comment #2)
> > I thought the SLP algorithm was bottom up and stores were
> > already sinks?
> Yeah, they are. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
--- Comment #2 from Tamar Christina ---
(In reply to rsand...@gcc.gnu.org from comment #1)
> (In reply to Tamar Christina from comment #0)
> > The SLP costs went from:
> >
> > Vector cost: 2
> > Scalar cost: 4
> >
> > to:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
Bug ID: 109072
Summary: [12/13 Regression] SLP costs for vec duplicate too
high since g:4963079769c99c4073adfd799885410ad484cbbe
Product: gcc
Version: 12.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #17 from Tamar Christina ---
(In reply to Segher Boessenkool from comment #13)
> Hi!
>
> Either this should not be P1, or the proposed patch is taking completely the
> wrong direction. P1 means there is a regression. There is no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
Tamar Christina changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #24 from Tamar Christina ---
> Sure that works I think, I'll do that then.
Just to check, I'm regtesting the patch, I assume you want me to revert the
hook as well right? Since nothing will be using it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #23 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #22)
> On Thu, 2 Feb 2023, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
> >
> > --- Comment #21 from Tamar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #21 from Tamar Christina ---
>
> OK, so that's an ADD_HIGHPART_EXPR then? Though the highpart of an
> add is only a single bit, isn't it? For scalar you'd use the
> carry bit here and instructions like adc to consume it. Is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #20 from Tamar Christina ---
> > I don't think so for addhn, because it wouldn't truncate the top bits, it
> > truncates the bottom bits.
> >
> > The instruction does
> > element1 = Elem[operand1, e, 2*esize];
> > element2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
--- Comment #8 from Tamar Christina ---
In case it helps, here's the reproducer on compiler explorer and the dump file
https://godbolt.org/z/dWvqexjnv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
Tamar Christina changed:
What|Removed |Added
Target||aarch64*
Summary|[13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #18 from Tamar Christina ---
> >
> > Ack, that also tracks with what I tried before, we don't indeed track ranges
> > for vector ops. The general case can still be handled slightly better (I
> > think)
> > but it doesn't become as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #15 from Tamar Christina ---
> OK, hopefully I understand now. Sorry for being slow.
Not at all, Sorry if it came across a bit cranky, it wasn't meant that way!
> If that's the condition we want to test for, it seems like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #12 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #11)
> On Tue, 31 Jan 2023, tnfchris at gcc dot gnu.org wrote:
>
>
> I don't think passing in for example the tree operand 0 helps, the
> target appearantly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #10 from Tamar Christina ---
(In reply to rsand...@gcc.gnu.org from comment #9)
> Are we sure this is a vectoriser vs. C vectors thing?
it's not, the issue we're debating is how to fix it.
As Richi pointed out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
--- Comment #6 from Tamar Christina ---
probably relevant that I can only reproduce it on an SVE/VLA system. non-VLA
works fine.
I have cvise running trying for a repro.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #7 from Tamar Christina ---
(In reply to rsand...@gcc.gnu.org from comment #6)
> (In reply to Tamar Christina from comment #3)
> > The vectorizer has this context but since we didn't want a new IFN the
> > context should instead be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
Bug ID: 108601
Summary: [13 Regression] vector peeling ICEs with PGO + LTO +
IPA inlining in gcc_r in SPEC2017
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #5 from Tamar Christina ---
> > The vectorizer has this context but since we didn't want a new IFN the
> > context should instead be derivable in
> > targetm.vectorize.can_special_div_by_const hook.
>
> The vectorizer doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
Tamar Christina changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108394
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925
--- Comment #5 from Tamar Christina ---
I seem to have the same failure in at least GCC 12 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97574
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108172
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108172
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=102218
--- Comment #4 from Tamar Christina ---
(In reply to ktkachov from comment #3)
> Does this need to be backported to other release versions as it's a
> wrong-code bug?
Yes Ideally. I did ask for backport but was only approved for master.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107988
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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=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=107830
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107830
Tamar Christina changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Tamar
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=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
Tamar Christina changed:
What|Removed |Added
Component|libstdc++ |libgcc
--- Comment #11 from Tamar
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
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=,
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
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
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 #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=107717
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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=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=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
Bug ID: 107675
Summary: [13 Regression] GCC-13 is significantly slower to
startup on C++ programs
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
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=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=89430
Tamar Christina changed:
What|Removed |Added
Status|REOPENED|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=107102
Bug ID: 107102
Summary: SVE function fails to realize it doesn't need the
frame-pointer in the tail call.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107026
Tamar Christina changed:
What|Removed |Added
CC||tneumann at users dot
sourceforge.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107026
Tamar Christina changed:
What|Removed |Added
Target|i586-msdosdjgpp |i586-msdosdjgpp,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106782
--- Comment #4 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #3)
> Tamar, any thoughts on that?
Apologies, didn't notice that earlier.
That should be "Target does not support vector type for %G\n"
with STMT_VINFO_STMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106524
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106744
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106744
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=106594
--- Comment #6 from Tamar Christina ---
Hi Roger,
before you spend too much time on this, I just wanted to clarify.
If you're saying this is a target issue where we lack some symmetry on patterns
I would be happy to fix it up and don't really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #4 from Tamar Christina ---
Hmm my concern here is though that we've now introduced two forms to represent
this and may cause an issue in other places where we sink extensions.
Perhaps there should be some canonization somewhere?
401 - 500 of 797 matches
Mail list logo
