I just realized that __reallocate_a and construct don't take the allocator
argument in the same position... I can switch if it helps.
Regtested on gcc112.
2018-10-25 Marc Glisse
PR libstdc++/87106
* include/bits/alloc_traits.h (_S_construct, _S_destroy, construct,
cialized
in future, so that I don't forget and simplify it to an alias template
later :-)
Ok.
--
Marc Glisse
ector,
produce (subreg (vec_duplicate X) 0), and let another transformation
optimize that.
(I had tried at some point to canonicalize subreg to vec_select to avoid
repeating such transformations, but it was rejected as a very bad idea)
--
Marc Glisse
On Sat, 13 Oct 2018, Marc Glisse wrote:
+ template
+struct __is_trivially_relocatable
+: is_trivially_move_constructible<_Tp> { };
Oups, this part is wrong, sorry, it is supposed to be "is_trivial" instead
of "is_trivially_move_constructible", to match
On Sat, 13 Oct 2018, Jonathan Wakely wrote:
On 13/10/18 11:07 +0200, Marc Glisse wrote:
--- libstdc++-v3/include/bits/alloc_traits.h(revision 265131)
+++ libstdc++-v3/include/bits/alloc_traits.h(working copy)
@@ -233,38 +233,43 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
using type
On Sun, 2 Sep 2018, Jonathan Wakely wrote:
On 01/09/18 21:56 +0200, Marc Glisse wrote:
On Sat, 1 Sep 2018, Marc Glisse wrote:
this patch passed bootstrap+regtest on powerpc64le-unknown-linux-gnu.
I realized afterwards that for a C++17-only feature, that's not testing
much... So I ch
happens if x*x gives +Inf) is thus completely fine unless you are using
crlibm, but then you wouldn't use flag_unsafe_math_optimizations. The main
issue is that if we have -ffast-math, we have -ffinite-math-only, and we
are possibly introducing an infinity as intermediate result...
--
Marc Glisse
On Mon, 1 Oct 2018, Richard Biener wrote:
On Sat, Sep 29, 2018 at 1:35 PM Marc Glisse wrote:
Hello,
I noticed quite ugly code from both testcases. This transformation does
not fix either, but it helps a bit.
I'm curious why you chose to restrict to INTEGER_CST A and B?
Is that becau
lect only picks from x. We could extend it to handle an
intermediate subreg/cast, which would yield something like:
(any_extend:V8HI (subreg:V8QI (match_operand:DI)))
or maybe even
(any_extend:V8HI (match_operand:V8QI))
Would this be likely to work? Is it desirable?
--
Marc Glisse
Hello,
I noticed quite ugly code from both testcases. This transformation does
not fix either, but it helps a bit.
bootstrap+regtest on powerpc64le-unknown-linux-gnu.
2018-09-30 Marc Glisse
gcc/
* match.pd (((X /[ex] A) +- B) * A): New transformation.
gcc/testsuite
g the code.
bootstrap+regtest on powerpc64le-unknown-linux-gnu.
2018-09-30 Marc Glisse
PR middle-end/87319
* fold-const.c (fold_plusminus_mult_expr): Handle complex and vectors.
* tree.c (signed_or_unsigned_type_for): Handle complex.
--
Marc GlisseIndex: gcc/fo
Hello,
here is a clang-friendly version of the patch (same changelog), tested a
while ago. Is it ok or do you prefer something like the
+ if(this->_M_impl._M_start._M_offset != 0) __builtin_unreachable();
version suggested by François?
--
Marc GlisseIndex: include/bits/stl_bvector.h
it_xor @0 @1) (bit_not:s (bit_ior @0 @1)))
+ (bit_not (bit_and @0 @1)))
:cs on the bit_xor, :s on the second bit_ior
Otherwise looks OK to me.
--
Marc Glisse
could help if gcc doesn't do it
itself already.
How would you use that precisely?
It may be easiest to use a different macro for trivial tests that can go
with __builtin_unreachable and for expensive tests that cannot.
--
Marc Glisse
ed for a
__builtin_unreachable. Is it using the wrong macro?
--
Marc Glisse
On Mon, 17 Sep 2018, Jonathan Wakely wrote:
On 17/09/18 21:24 +0200, Marc Glisse wrote:
On Mon, 17 Sep 2018, Marc Glisse wrote:
On Mon, 17 Sep 2018, Jonathan Wakely wrote:
Do other compilers besides gcc suppress the same way?
No, clang doesn't:
What version is that? I didn'
On Mon, 17 Sep 2018, Marc Glisse wrote:
On Mon, 17 Sep 2018, Jonathan Wakely wrote:
Do other compilers besides gcc suppress the same way?
No, clang doesn't:
What version is that? I didn't test on this exact patch, but clang 6 and
7 print, for similar code:
warning: g
[-Wc++11-extensions]
So I do think we should stick to C++98 syntax.
What is the oldest version of clang we are supposed to support? I
thought historically we mostly supported whatever version of clang was
released *after* (i.e. clang does the support).
--
Marc Glisse
On Mon, 17 Sep 2018, Jonathan Wakely wrote:
On 15/09/18 14:27 +0200, Marc Glisse wrote:
Hello,
as explained in the PR, the implementation of vector is weirdly
wasteful. Preserving the ABI prevents from changing much for now, but this
small tweak can help the compiler remove quite a bit of
header.
Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
2018-09-15 Marc Glisse
PR libstdc++/87258
* include/bits/stl_bvector.h (vector::begin(), vector::cbegin()):
Rebuild _M_start with an explicit 0 offset.
--
Marc GlisseIndex: include/bits/stl_bvector.h
. Maybe
(simplify
(bit_ior:c (bit_and:c (bit_not@2 @0) @1) (bit_not (bit_ior:c @0 @1)))
@2)
--
Marc Glisse
one just on the last bit_xor seems strange.
+/* (x ^ y) | ~(x | y) -> ~(x & y) */
+(simplify
+ (bit_ior:c (bit_xor:s @0 @1) (bit_not (bit_ior:s @0 @1)))
+ (bit_not (bit_and @0 @1)))
bit_not:s
--
Marc Glisse
On Sun, 2 Sep 2018, Bernhard Reutner-Fischer wrote:
On 30 August 2018 22:20:06 CEST, Marc Glisse wrote:
Hello,
INTEGRALS_SIGN_PREC_MATCH: the name doesn't really match the semantics.
+#define INTEGRALS_SIGN_PREC_MATCH(A, B) \
+ TYPE_PRECISION (TREE_TYPE (A)) == TYPE_PREC
On Sat, 1 Sep 2018, Marc Glisse wrote:
this patch passed bootstrap+regtest on powerpc64le-unknown-linux-gnu.
I realized afterwards that for a C++17-only feature, that's not testing
much... So I changed it to apply in C++14 and fixed a minor issue. There
is now a single regre
I forgot to attach the "diff -w" version of the patch, which may be a bit
more readable.
--
Marc GlisseIndex: include/bits/alloc_traits.h
===
--- include/bits/alloc_traits.h (revision 264027)
+++ include/bits/alloc_traits.h (working
x27;t look elsewhere.
* specialize relocation for some types (maybe deque?) where it can be
noexcept, possibly even trivial, whereas the move constructor cannot. If
we do that, we may want to specialize for pair/tuple/array as well, in
case one of the members is specialized.
2018-09-01 Marc
(cst), but that's not easy to formulate.
I was surprised not to see the impossible cases like ((a & b) < 0) & (a >=
0), but I don't mind their absence.
Other than those details, I think the patch looks good, thanks. (I am not
a reviewer)
--
Marc Glisse
c' markers of the bit_ior's
+ (bit_not (bit_xor @0 @1)))
+
+/* (~x | y) ^ (x | ~y) -> x ^ y */
+(simplify
+ (bit_xor (bit_ior:c (bit_not @0) @1) (bit_ior:c @0 (bit_not @1)))
+ (bit_xor @0 @1))
Likewise.
Wouldn't :s be ignored here, since there is a single instruction in the
output?
--
Marc Glisse
manually checked
that the attribute has an effect.
2018-08-25 Marc Glisse
PR libstdc++/86822
* libsupc++/new (operator new(size_t, nothrow_t), operator
new[](size_t, nothrow_t), operator new(size_t, align_val_t, nothrow_t),
operator new[](size_t, align_val_t
nt s)
+{
+ return ~(~(x|s)|x)|~(~(x|s)|s);
+}
+
+int f2 (int x, int s)
+{
+ return ~(~(~x&s)&~(x&~s));
+}
+
+int f3 (int x, int s)
+{
+ return ~((x|~s)&(~x|s));
+}
+
+int f4 (int x, int s)
+{
+ return (~x|s)&(x|~s);
+}
--
Marc Glisse
On Fri, 17 Aug 2018, Jonathan Wakely wrote:
On 17/08/18 19:28 +0200, Marc Glisse wrote:
On Mon, 13 Aug 2018, Jonathan Wakely wrote:
Thanks to Lars for the suggestions.
* libsupc++/new_opa.cc (operator new(size_t, align_val_t)): Use
__is_pow2 to check for valid alignment
at gcc immediately replaces ~(align - 1) with -align. It does it
even if you compute align-1 on the previous line and write (sz+X)&~X in
the hope of sharing the subtraction.
--
Marc Glisse
On Sun, 5 Aug 2018, MCC CS wrote:
Besides, if you think optimizing
/* logN(a) + logN(b) -> logN(a * b) */
would be enough, without the coefficients,
here's a simpler patch:
Index: gcc/match.pd
===
--- gcc/match.pd(revision 2633
m in the
minority...
--
Marc Glisse
On Sun, 5 Aug 2018, MCC CS wrote:
this patch reduces calls to logarithm functions by
merging log a + log b => log a*b and
this makes sense.
+ /* x * logN(a) + y * logN(b) -> x * y * logN(a * b). */
this on the other hand... Can you explain the math?
--
Marc Glisse
7;t have a strong opinion on what the best approach is.
--
Marc Glisse
_mm_move_ss.
--
Marc Glisse
On Wed, 1 Aug 2018, Martin Liška wrote:
On 08/01/2018 02:25 PM, Marc Glisse wrote:
On Wed, 1 Aug 2018, Martin Liška wrote:
On 07/27/2018 02:38 PM, Marc Glisse wrote:
On Fri, 27 Jul 2018, Martin Liška wrote:
So answer is yes, the builtin can be then removed.
Good, thanks. While looking
On Wed, 1 Aug 2018, Martin Liška wrote:
On 07/27/2018 02:38 PM, Marc Glisse wrote:
On Fri, 27 Jul 2018, Martin Liška wrote:
So answer is yes, the builtin can be then removed.
Good, thanks. While looking at how widely it is going to apply, I noticed that the
default, throwing operator new
(you would somehow need one pointer close to 0
and the other close to 2^32 so they end up close modulo 2^32, but that
would require @2+@1 to overflow which means the loop will never run that
far anyway).
But we are still lying and taking a risk that some other optimization
will trust us. (I am
k, the 2 pointers are possibly
unrelated, so maybe the code emitted for an alias check should be
changed.
--
Marc Glisse
doesn't, so it
won't benefit from the new predictor. I don't know if there is a good
reason for this disparity...
--
Marc Glisse
(bad_alloc());
handler ();
}
where being in a loop may trigger opposite heuristics.
--
Marc Glisse
ow if some similar helper will
still be necessary, with a simpler implementation, or if the attribute
will magically get rid of it?
(I haven't looked at it at all, the answer may be obvious)
--
Marc Glisse
can't use scan-tree-dump in the libstdc++
testsuite, if you wanted to add one. We do have other dg-final tests.
The others only test for the presence of some name in assembly. But I may
try it later.
--
Marc Glisse
n
the libstdc++ testsuite. The closest would be g++.dg/pr83239.C,
g++.dg/vect/pr64410.cc, g++.dg/vect/pr33426-ivdep-4.cc that include
, but from previous experience (already with vector), adding
libstdc++ testcases to the C++ testsuite is not very popular.
Bootstrap+regtest on powerpc64l
*/
+ (with { tree ptr1 = @0, ptr2 = @2;
+ if (tree_swap_operands_p (ptr1, ptr2))
+ std::swap (ptr1, ptr2); }
+ (gt (plus (minus (convert:sizetype { ptr1; })
+ (convert:sizetype { ptr2; }))
+{ wide_int_to_tree (sizetype, off); })
+ { wide_int_to_tree (sizetype, off * 2); }
--
Marc Glisse
On Sat, 7 Jul 2018, Jakub Jelinek wrote:
On Sat, Jul 07, 2018 at 11:55:17AM +0200, Marc Glisse wrote:
On Sat, 7 Jul 2018, Jakub Jelinek wrote:
2018-07-07 Jakub Jelinek
PR c/86420
* real.c (real_nextafter): Return true if result is denormal.
I have a question on the side
ld be that we have the value of _2 and can keep
folding its uses.
--
Marc Glisse
e future?
It is confusing.
--
Marc Glisse
don't apply
here...
--
Marc Glisse
e existing functions
might be a better approach?)
tree_expr_nonzero_p (don't know why the comment above talks about
addresses), expr_not_equal_to.
--
Marc Glisse
h s
where the fact that s has a different length in lines 2 and 4 is hidden by
the patch. But maybe all the transformations are carefully written to
avoid this problem...
--
Marc Glisse
On Thu, 24 May 2018, Martin Sebor wrote:
On 05/24/2018 03:40 PM, Marc Glisse wrote:
On Wed, 23 May 2018, Martin Sebor wrote:
On 05/23/2018 08:57 AM, Jeff Law wrote:
On 05/10/2018 04:05 PM, Marc Glisse wrote:
On Thu, 10 May 2018, Martin Sebor wrote:
Can you please comment/respond to
On Wed, 23 May 2018, Martin Sebor wrote:
On 05/23/2018 08:57 AM, Jeff Law wrote:
On 05/10/2018 04:05 PM, Marc Glisse wrote:
On Thu, 10 May 2018, Martin Sebor wrote:
Can you please comment/respond to Jeff's question below and
confirm whether my understanding of the restriction (belo
has scalar integer type (in particular not a vector type).
Or more precisely asking why such a check is done for PLUS_EXPR and not
for LSHIFT_EXPR.
--
Marc Glisse
On Fri, 18 May 2018, Jakub Jelinek wrote:
On Fri, May 18, 2018 at 09:02:08AM -0400, Nathan Sidwell wrote:
On 05/18/2018 08:53 AM, Marc Glisse wrote:
As long as you do not dereference ptr in the constructor, that shouldn't
contradict 'restrict'. The PR gives this quote fr
On Fri, 18 May 2018, Nathan Sidwell wrote:
On 05/18/2018 08:53 AM, Marc Glisse wrote:
As long as you do not dereference ptr in the constructor, that shouldn't
contradict 'restrict'. The PR gives this quote from the standard:
"During the construction of an object, if the
On Fri, 18 May 2018, Nathan Sidwell wrote:
On 05/18/2018 08:34 AM, Marc Glisse wrote:
(Cc: said C++ folks)
On Fri, 18 May 2018, Richard Biener wrote:
On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote:
Hello,
this lets alias analysis handle the implicit 'this' para
(Cc: said C++ folks)
On Fri, 18 May 2018, Richard Biener wrote:
On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote:
Hello,
this lets alias analysis handle the implicit 'this' parameter in C++
constructors as if it was restrict.
Bootstrap+regtest on powerpc64le-unknown-linux
Hello,
this lets alias analysis handle the implicit 'this' parameter in C++
constructors as if it was restrict.
Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
2018-05-18 Marc Glisse
PR c++/82899
gcc/
* tree-ssa-structalias.c (create_variable_info_for
On Thu, 17 May 2018, Richard Biener wrote:
On Thu, May 17, 2018 at 1:14 PM Marc Glisse wrote:
On Thu, 17 May 2018, Jonathan Wakely wrote:
On 17/05/18 12:54 +0200, Marc Glisse wrote:
On Mon, 14 May 2018, Jonathan Wakely wrote:
As discussed at https://gcc.gnu.org/ml/libstdc++/2018-01
On Thu, 17 May 2018, Jonathan Wakely wrote:
On 17/05/18 12:54 +0200, Marc Glisse wrote:
On Mon, 14 May 2018, Jonathan Wakely wrote:
As discussed at https://gcc.gnu.org/ml/libstdc++/2018-01/msg00073.html
we can simplify the allocator function for valarray memory. I also
noticed that the
7;restrict' when
inlining a function with attribute malloc?) and all that matters is
operator new.
--
Marc Glisse
ld be
interested in looking at your approach.
--
Marc Glisse
_DIFF_EXPR more)
--
Marc Glisse
On Thu, 10 May 2018, Hans-Peter Nilsson wrote:
Date: Thu, 10 May 2018 10:33:39 +0200 (CEST)
From: Marc Glisse
On Thu, 10 May 2018, Hans-Peter Nilsson wrote:
Replacing a division feeding a division helps only when the
second division is the only user, and "fusing" the divisions
, etc. And not all of those
want exactly the same conditions.
It is useful for high-level transformations to push the canonicalization
as far as possible, to notice equivalent quantities or constant bounds in
particular. So on a case by case basis, we use :s or single_use or
whatever...
If we use both y=x/3 and z=x/15 in the same function, should we make an
effort to detect it and rewrite to z=y/5?
--
Marc Glisse
case?
You cannot use bit_xor because the bits are only *possibly* set (same as
you can't say anything about BIT_NOT_EXPR). We would need to also track
the bits *certainly* set to start doing clever stuff, and for BIT_XOR_EXPR
that would still be inconvenient.
--
Marc Glisse
+ rep (eq eq ne ne)
+(simplify
+ (cmp (popcount @0) zerop)
Might as well use integer_zerop when we know we are dealing with integers.
+ (rep @0 { build_zero_cst (TREE_TYPE (@0)); }
Nice patch :-)
--
Marc Glisse
Ping https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02233.html
On Sat, 25 Nov 2017, Marc Glisse wrote:
Hello,
the way full masks are generated currently in avx2intrin.h is questionable:
opaque for the inline functions, weird/wrong for the macros.
It is possible we may want to add code so
s or infinities, just an underflow. First, the result depends
on the rounding mode. And in the default round-to-nearest, both divisions
give 0, and thus compare the same with 0, but we replace that with a sign
test on x, where they clearly give opposite answers.
What would be the proper flag
Hello,
this transformation was lacking symmetry, only handling & and not |.
It probably still fails to handle a < b & a <= 123, while it would handle
< 124, but that's for another day.
Bootstrap+testsuite on powerpc64le-unknown-linux-gnu.
2018-05-01 Marc Gli
On Thu, 19 Apr 2018, Richard Biener wrote:
On Thu, 19 Apr 2018, Marc Glisse wrote:
On Thu, 19 Apr 2018, Jakub Jelinek wrote:
As mentioned in the PR, this optimization can't work if @0's precision
is higher than @1's precision, because originally it compares just some set
of
ntermediate cast to a 64-bit integer, even if
verify_gimple_assign_unary allows the direct cast. Does it depend on the
platform? It might be nice to canonicalize this a bit, either by
forbidding narrowing pointer-to-integer casts, or by simplifying cast
chains to direct casts.
--
Marc Glisse
they didn't
optimize as aggressively and so the stack space of the expired
temporaries wasn't reused (ASan still shows the bug was there in older
releases even if it doesn't crash). As a regression this should be
backported, but the layout changes make me pause a little when
considering mak
* expr.c (compare_by_pieces): Add support for bail out.
(emit_block_move_hints): Likewise.
* expr.h (emit_block_move_hints): Add new arguments.
--
Marc Glisse
On Thu, 1 Mar 2018, Jakub Jelinek wrote:
Note ia64, pa and powerpcspe likely need to be fixed too to predefine
__SIZEOF_FLOAT128__=16 if they provide __float128.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56540
(it only mentions ia64)
--
Marc Glisse
nsure that _GLIBCXX_USE_FLOAT128 is undefined instead?
By the way, __FLOAT128__ is power-only. x86 has __SIZEOF_FLOAT128__
instead (why did power pick a different name?).
--
Marc Glisse
On Wed, 14 Feb 2018, Richard Biener wrote:
On Tue, 13 Feb 2018, Marc Glisse wrote:
On Tue, 13 Feb 2018, Richard Biener wrote:
On February 13, 2018 6:51:29 PM GMT+01:00, Jakub Jelinek
wrote:
Hi!
On the following testcase, we recurse infinitely, because
we have float re-association enabled
seems strange
to me, and likely not worth optimizing for.
--
Marc Glisse
No :c on the first mult, so we don't actually handle A*C+B*C?
--
Marc Glisse
s), and I can understand that in stage 3 you are more interested
in an approach that looks like a reversal to a former known-ok state.
--
Marc Glisse
oid*f(){return 0;}
are any of the properties of the malloc attribute violated? It seems to
me that if you reject malloc(0), then even the standard malloc function
should be rejected as well...
--
Marc Glisse
On Thu, 11 Jan 2018, Marc Glisse wrote:
On Thu, 11 Jan 2018, François Dumont wrote:
- void _M_swap_data(_Vector_impl& __x) _GLIBCXX_NOEXCEPT
+ void
+ _M_swap_data(_Vector_impl_data& __x) _GLIBCXX_NOEXCEPT
{
std::swap(_M_start, __x._M_start);
s
M_finish);
std::swap(_M_end_of_storage, __x._M_end_of_storage);
}
I don't remember earlier discussions about this patch, but is this piece
of code still needed? std::swap(*this, __x) looks like it should work.
--
Marc Glisse
p; !HONOR_INFINITIES, then you don't even need
your REAL_VALUE_ISINF test.
--
Marc Glisse
On Wed, 3 Jan 2018, Martin Liška wrote:
+ *cleanup_eh = maybe_clean_or_replace_eh_stmt (stmt,
+ stmt);
Do you mean *cleanup_eh |= ... ?
--
Marc Glisse
share a testcase? Did you check if it passes the
testsuite (I don't remember if there is a specific testcase for this)?
--
Marc Glisse
it is wrong by observation.
Tested on aarch64-none-elf and bootstrapped on aarch64-none-linux-gnu with
no issues.
OK?
Thanks,
James
---
2017-12-11 James Greenhalgh
* combine.c (simplify_set): Do not transform subregs to zero_extends
if the destination mode is a vector mode.
--
Marc Glisse
- CST1) +- CST2 -> A + CST3"
elsewhere in the file. Do you think there is a convenient way to
generalize it so it also covers this case, or does it look better to keep
them separate? (I haven't had time to study your recent patches yet, so I
don't have an opinion)
--
Marc Glisse
Adding Cc: Uros and Kirill
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02233.html
On Sat, 25 Nov 2017, Marc Glisse wrote:
Hello,
the way full masks are generated currently in avx2intrin.h is questionable:
opaque for the inline functions, weird/wrong for the macros.
It is possible we may
On Mon, 4 Dec 2017, Martin Sebor wrote:
On 12/04/2017 03:44 PM, Marc Glisse wrote:
On Mon, 4 Dec 2017, Martin Sebor wrote:
The -Wplacement-new option warns for buffer overflow in placement
new expressions with objects of constant sizes, but because it's
implemented completely in
riate even at this stage?
AFAIK, one can call this operator new manually on any pointer, including
one-past-the-end pointers and null pointers. It is only with new
expressions that the limitation comes in (because it runs a constructor
afterwards). Not that people often do that...
--
Marc Glisse
,
but that looks like something that should be decided globally, not in each
instruction that uses it.
Bootstrap+regtest on x86_64-pc-linux-gnu (skylake).
2017-11-27 Marc Glisse
PR target/80885
* config/i386/avx2intrin.h (_mm_i32gather_pd): Rewrite mask generation
ode further in the function expects to be able to adjust args, which is
defeated by copying them in align_args, see PR 82760.
--
Marc Glisse
On Thu, 23 Nov 2017, Richard Biener wrote:
What about 0 - ptr? (ok, that's even more weird)
* match.pd (0-ptr): New transformation.
Regtested on gcc112.
--
Marc GlisseIndex: gcc/match.pd
===
--- gcc/match.pd (revision 2
:
‘IX86_BUILTIN__BDESC_SPECIAL_ARGS2_FIRST’ was not declared in this scope
BDESC_VERIFYS (IX86_BUILTIN__BDESC_SPECIAL_ARGS2_FIRST,
^
--
Marc Glisse
On Thu, 23 Nov 2017, Richard Biener wrote:
On Wed, Nov 22, 2017 at 6:34 PM, Marc Glisse wrote:
Hello,
I hadn't implemented this simplification because I think it is invalid code,
but apparently people do write it, so we might as well handle it sensibly.
This also happens to work arou
might want to check with the committee if optimizing more calls is
ok.
--
Marc Glisse
201 - 300 of 1598 matches
Mail list logo
