https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #10 from Tamar Christina ---
Just finished second bisect and reduce. Came out to this commit as well.
---
module brute_force
integer, parameter :: r=9
integer sudoku1(1, r)
contains
subroutine brute
integer
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=106196
Tamar Christina changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
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|REOPENED
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=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 #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=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=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=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=106253
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
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=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 #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
--- 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
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=105874
--- Comment #8 from Tamar Christina ---
Can confirm that the benchmark works again.
Thanks!
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=106346
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=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=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=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=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=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
Target|i586-msdosdjgpp |i586-msdosdjgpp,
|
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=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=106519
Tamar Christina changed:
What|Removed |Added
CC||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
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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 #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=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=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=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=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
Summary|[12/13 Regression] ICE in |[12 Regression] ICE in
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?
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=106519
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
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=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=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=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=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=107830
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
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=107717
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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
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=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=108583
Tamar Christina changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
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=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=108394
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
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
--- 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
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=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=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=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 #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
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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=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=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=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=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.
301 - 400 of 750 matches
Mail list logo
