. The result is never more
complicated than the original. Sure, it might increase register pressure a
bit in some cases, but we have not used that as a criterion for other
simplifications in match.pd yet (LLVM does though).
--
Marc Glisse
it.
--
Marc Glisse
.
Would it be ok to always turn it to X=31 then? (the value 31 is
conveniently already computed in 'cand')
--
Marc Glisse
On Tue, 9 Jun 2015, Richard Biener wrote:
On Tue, 9 Jun 2015, Richard Biener wrote:
On Tue, 9 Jun 2015, Marc Glisse wrote:
On Tue, 9 Jun 2015, Richard Biener wrote:
Tweaking it so that (6X)==0 becomes X=31 for TYPE_OVERFLOW_WRAPS and
false for TYPE_OVERFLOW_UNDEFINED is probably more
could also return 0 when the candidate turns out not to work: (3x)==4.
Tweaking it so that (6X)==0 becomes X=31 for TYPE_OVERFLOW_WRAPS and
false for TYPE_OVERFLOW_UNDEFINED is probably more controversial.
FWIW, the patch looks good to me, thanks.
--
Marc Glisse
from a time when it wasn't?
--
Marc Glisse
,
otherwise the overloads are ambiguous.
Ah, I had overlooked that. I have seen several work-arounds for this
issue, but I don't remember this one, it seems nice.
--
Marc Glisse
give less clutter when you
have to repeat it 4 times.
--
Marc Glisse
(ops1[2]) : TREE_TYPE (ops1[1])
but I don't think that will be necessary.
Bootstrap is currently broken on many platforms with comparison failures,
but since it went that far and generated the same *-match.c files, that
seems sufficient testing.
2015-06-08 Marc Glisse marc.gli...@inria.fr
)
{
V t = __builtin_shuffle (*a, *b, *c);
V v = __builtin_shuffle (t, (V) { ~0U, ~0U, ~0U, ~0U, ~0U, ~0U, ~0U, ~0U },
(V) { 0, 1, 8, 3, 4, 5, 9, 7 });
--
Marc Glisse
one, by
default (expr::gen_transform already has a few special cases).
--
Marc Glisse
or something, we can always
add checks:
(simplify
(cmp CONSTANT_CLASS_P@0 @1)
(if (!zerop (@1))
(scmp @1 @0)))
(hmm, I didn't add zerop to tree.[hc] yet) or !CONSTANT_CLASS_P (@1) or
whatever is necessary.
--
Marc Glisse
count, otherwise give up?
ctz(CST2)-ctz(CST1) should provide a single candidate without looping.
ctz(CST1) is also relevant when CST2==0.
--
Marc Glisse
with
__builtin_unreachable();
then? It seems strange to keep an implementation that is never supposed to
be used.
--
Marc Glisse
this _S_ref an arbitrary
abi_tag. You could also replace all uses of _S_ref with *_S_ptr.
--
Marc Glisse
are asserting that x is not
INT_MIN.
--
Marc Glisse
@0))
without success. There is already a comment for logical_inverted_value
about related limitations in genmatch.
--
Marc Glisse
Hello,
I noticed we were only doing this transformation for floats and not for
integers, so I took the chance to move it to match.pd. Regtested on
ppc64le-redhat-linux.
2015-05-25 Marc Glisse marc.gli...@inria.fr
* match.pd (swapped_tcc_comparison): New operator list
was generating
a switch with duplicate cases (miraculously, replacing 'cond' with an
iteration on 'cnd' worked around it). Second, (plus @0 (negate@0 @1)) is
treated as (plus @0 @0), the pattern on the second occurence of the
capture is silently ignored.
Regtested on ppc64le-redhat-linux.
2015-05-25 Marc
On Mon, 18 May 2015, Richard Biener wrote:
On Fri, May 15, 2015 at 7:22 PM, Marc Glisse marc.gli...@inria.fr wrote:
we already have the more complicated: x ~(x y) - x ~y (which I am
reindenting by the way) and the simpler: (~x | y) x - x y, so I am
proposing this one for completeness
On Mon, 18 May 2015, Richard Biener wrote:
On Thu, May 14, 2015 at 4:28 PM, Jeff Law l...@redhat.com wrote:
On 05/14/2015 08:04 AM, Marc Glisse wrote:
On Fri, 1 May 2015, Jeff Law wrote:
Slight refactoring of the condition by using types_match as suggested
by Richi. I also applied the new
Hello,
first, this patch is not ready (it doesn't even bootstrap), I am posting
it for comments. The idea is, when we do value numbering, while looking
for the current value of a local variable, we may hit a clobber or reach
the beginning of the function. In both cases, it seems to me that we
Hello,
this patch was regtested on ppc64le-redhat-linux.
2015-05-15 Marc Glisse marc.gli...@inria.fr
gcc/
* convert.c (convert_to_integer, convert_to_vector): Include the
types in the error message.
gcc/testsuite/
* gcc.dg/simd-1.c: Update to the new message.
--
Marc
scalars
here.
Regtested on ppc64le-redhat-linux.
2015-05-15 Marc Glisse marc.gli...@inria.fr
PR tree-optimization/63387
gcc/
* match.pd ((X /[ex] A) * A - X): Remove unnecessary condition.
((x ord x) (y ord y) - (x ord y),
(x ord x) (x ord y) - (x ord y)): New
Hello,
we already have the more complicated: x ~(x y) - x ~y (which I am
reindenting by the way) and the simpler: (~x | y) x - x y, so I am
proposing this one for completeness. Regtested on ppc64le-redhat-linux.
2015-05-15 Marc Glisse marc.gli...@inria.fr
gcc/
* match.pd ((x
a
different type for trees and types, this would be overloading the
function. We already do this in a few places, and I find the resulting
shorter code more readable.
2015-05-14 Marc Glisse marc.gli...@inria.fr
* generic-match-head.c (types_match): Handle non-types.
* gimple
becoming a bit complicated.
2015-05-15 Marc Glisse marc.gli...@inria.fr
PR tree-optimization/64454
gcc/
* match.pd ((X % Y) % Y, (X % Y) Y): New patterns.
(-1 - A - ~A): Remove unnecessary condition.
gcc/testsuite/
* gcc.dg/modmod.c: New testcase.
--
Marc
-NAN rho and finite theta, as
decided for by the LWG 2439?
non-NAN rho is already covered by rho = 0.
--
Marc Glisse
Hello,
here is a rewrite of the patch, using wide_int, and improving a bit the
result. Same ChangeLog, tested again on x86_64-linux-gnu.
--
Marc GlisseIndex: gcc/testsuite/gcc.dg/tree-ssa/vrp97.c
===
---
On Mon, 4 May 2015, Richard Biener wrote:
On Sat, May 2, 2015 at 12:46 AM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
this patch tries to tighten a bit the range estimate for x%y. slp-perm-7.c
started failing by vectorizing more than expected, I assumed it was a good
thing and updated
ones.
--
Marc Glisse
the interesting functions were too hard to
write as one-liners...
--
Marc Glisse
On Sat, 2 May 2015, Jonathan Wakely wrote:
On 02/05/15 18:27 +0200, Marc Glisse wrote:
On Sat, 2 May 2015, Jonathan Wakely wrote:
These where simple to implement (almost too simple ... I probably
got something wrong!)
I didn't remember that std::abs works for unsigned. It will need more
On Sat, 2 May 2015, Jonathan Wakely wrote:
std::abs seems to work fine for unsigned, the overload in cmath for
integral types just uses __builtin_fabs.
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2192
That overload should die.
--
Marc Glisse
are
supposed to be represented in VRP.
Bootstrap+testsuite on x86_64-linux-gnu.
2015-05-02 Marc Glisse marc.gli...@inria.fr
PR tree-optimization/64454
gcc/
* tree-vrp.c (extract_range_from_binary_expr_1) TRUNC_MOD_EXPR:
Rewrite.
gcc/testsuite/
* gcc.dg/tree-ssa
)
+ (with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
+ (convert (bit_and (op (convert:utype @0) (convert:utype @1))
+ (convert:utype @4)))
--
Marc Glisse
)))
+ (convert (op @0 (convert @1
(with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
(convert (op (convert:utype @0) (convert:utype @1)))
--
Marc Glisse
a ChangeLog entry is missing as well as stating
how you tested the patch.
Thanks,
Richard.
+ (if ((TREE_CODE (@2) != SSA_NAME || has_single_use (@2))
+cst integer_pow2p (cst))
+ (bit_and (plus @0 @1) (bit_not @1)
--
Marc Glisse
On Thu, 30 Apr 2015, Jeff Law wrote:
On 04/30/2015 01:17 AM, Marc Glisse wrote:
+/* This is another case of narrowing, specifically when there's an outer
+ BIT_AND_EXPR which masks off bits outside the type of the innermost
+ operands. Like the previous case we have to convert
Hello,
this patch fixes an obvious typo. Regtested without problem, and I
manually checked that the new return value of max() makes more sense.
2015-04-28 Marc Glisse marc.gli...@inria.fr
PR libstdc++/65883
* include/std/limits (numeric_limits): Add missing unsigned
of the 2 anti-ranges, which one it picks is pretty
arbitrary. It probably warns if you swap the tests for 0 and -2.
--
Marc Glisse
of the function
can never make sense (unreachable or undefined behavior), it is good that
the compiler tells you about it.
--
Marc Glisse
is a new version that also passes the tests. I guess we will have
plenty of time during stage1 to notice if it causes problems. We could
probably move the new definitions of __distance to
bits/stl_iterator_base_funcs.h, I don't have a clear preference.
2015-04-14 Marc Glisse marc.gli...@inria.fr
On Mon, 13 Apr 2015, Marc Glisse wrote:
On Mon, 13 Apr 2015, Richard Biener wrote:
On Mon, Apr 13, 2015 at 2:23 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
just a simple pattern for match.pd. I am ignoring the issue of whether
isnan
is the same as isunordered, I am only combining
on wrapping the size of std::list in a _List_nodesize_t for
gcc-5, which may look a bit strange at first sight.
2015-04-13 Marc Glisse marc.gli...@inria.fr
PR libstdc++/61347
* include/bits/stl_iterator_base_funcs.h (distance): Do not
qualify the call to __distance
On Mon, 13 Apr 2015, Jonathan Wakely wrote:
On 13/04/15 13:42 +0200, Marc Glisse wrote:
this patch makes std::distance(list.first(),list.end()) a constant time
operation when optimizing, with no penalty for other calls. We could do the
test always (no __builtin_constant_p
Hello,
just a simple pattern for match.pd. I am ignoring the issue of whether
isnan is the same as isunordered, I am only combining isunordered
together.
2015-04-13 Marc Glisse marc.gli...@inria.fr
PR tree-optimization/63387
gcc/
* match.pd ((x unord x) | (y unord y) - (x
On Mon, 13 Apr 2015, Richard Biener wrote:
On Mon, Apr 13, 2015 at 2:23 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
just a simple pattern for match.pd. I am ignoring the issue of whether isnan
is the same as isunordered, I am only combining isunordered together.
Ok.
Oups, I am
-pattern.
--
Marc Glisse
of the outer mode?
I've added an assert to make sure that the second element is not also a
const_int, as a vec_concat of const_ints doesn't make sense as far as I
can see.
--
Marc Glisse
there
is an andn insn). So I believe the 2 main options are:
- move @2 on the bit_not
- don't test has_single_use at all
--
Marc Glisse
On Wed, 14 Jan 2015, Richard Biener wrote:
On Wed, Jan 14, 2015 at 1:45 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Tue, 13 Jan 2015, Rasmus Villemoes wrote:
diff --git gcc/match.pd gcc/match.pd
index 81c4ee6..04a0bc4 100644
--- gcc/match.pd
+++ gcc/match.pd
@@ -262,6 +262,16 @@ along
*/
+(simplify
+ (plus @0 (bit_and @0 integer_onep@1))
+ (bit_and (plus @0 @1) (bit_not @1)))
+
+/* x | ~(x | y) - x | ~y */
+(simplify
+ (bit_ior @0 (bit_not (bit_ior @0 @1)))
+ (bit_ior @0 (bit_not @1)))
You may want to consider using has_single_use (see other patterns).
--
Marc Glisse
Hello,
after HONOR_NANS, I am turning the other HONOR_* macros into functions. As
a reminder, the goal is both to make uses shorter and to fix the answer
for non-native vector types.
Bootstrap+testsuite on x86_64-linux-gnu.
2014-12-12 Marc Glisse marc.gli...@inria.fr
* real.h
reason why you are avoiding ANY_INTEGRAL_TYPE_P in
any_integral_type_check?
--
Marc Glisse
types would be
helpful (like FLOAT_TYPE_P).
--
Marc Glisse
with a debian-based system (assuming we are talking
about the same thing). I believe it was documented somewhere, Paolo should
know.
--
Marc Glisse
and not gcond*, so I
didn't.
Passes bootstrap+testsuite on x86_64-linux-gnu.
2014-12-08 Marc Glisse marc.gli...@inria.fr
* real.h (HONOR_NANS): Replace macro with 3 overloaded declarations.
* real.c: Include rtl.h and options.h.
(HONOR_NANS): Define three overloads
integer_all_onesp @0)
+ (if (TREE_CODE (type) != COMPLEX_TYPE)
+(bit_not @0)))
It should also be true for COMPLEX_TYPE where integer_all_onesp tests for
-1-i.
(I know you are just copying from fold-const)
--
Marc Glisse
), overflow_p);
+ }
+ (if (!overflow_p)
+(div @0 { wide_int_to_tree (type, mul); }))
+ (if (overflow_p)
+{ build_zero_cst (type); }
+
Can't you have something like:
INT_MIN / 2 / (INT_MIN / -2) == -1
where
2 * (INT_MIN / -2)
overflows?
--
Marc Glisse
On Mon, 17 Nov 2014, Richard Biener wrote:
On Sun, Nov 16, 2014 at 6:53 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Sun, 16 Nov 2014, Richard Biener wrote:
I think the element_mode is the way to go.
The following passed bootstrap+testsuite.
2014-11-16 Marc Glisse marc.gli
On Tue, 18 Nov 2014, James Greenhalgh wrote:
On Wed, Nov 05, 2014 at 11:31:24PM +, James Greenhalgh wrote:
On Wed, Nov 05, 2014 at 09:50:52PM +, Marc Glisse wrote:
Thanks. Do you know if anyone is planning to port this patch to the arm
target (which IIRC has the same issue
Hello,
this patch breaks gcc.dg/torture/pr50396.c, and I believe this is a
symptom of a bigger issue: the HONOR_NANS interface is bad (or at least
the way we are using it is bad). To know if a type honors NaN, we first
get its TYPE_MODE and then call HONOR_NANS on that. But for vectors that
On Sun, 16 Nov 2014, Richard Biener wrote:
I think the element_mode is the way to go.
The following passed bootstrap+testsuite.
2014-11-16 Marc Glisse marc.gli...@inria.fr
* tree.c (element_mode, integer_truep): New functions.
* tree.h (element_mode, integer_truep
On Sun, 16 Nov 2014, Marc Glisse wrote:
On Sun, 16 Nov 2014, Richard Biener wrote:
I think the element_mode is the way to go.
The following passed bootstrap+testsuite.
2014-11-16 Marc Glisse marc.gli...@inria.fr
* tree.c (element_mode, integer_truep): New functions
On Wed, 12 Nov 2014, Jonathan Wakely wrote:
On 12/11/14 07:13 +0100, Marc Glisse wrote:
On Tue, 11 Nov 2014, Jonathan Wakely wrote:
+ templatetypename _Iterator, typename = __void_t
Is there a particular reason not to write void directly?
I like this form as a hint
, I don't believe it will be portable everywhere.
Can't you use
INTTYPE_MAXIMUM (int64_t) instead of INT64_MAX? We already use that
in GCC...
We could also start using the standard C++ mechanism (numeric_limits).
(nothing wrong with INTTYPE_MAXIMUM, just an alternative)
--
Marc Glisse
On Tue, 11 Nov 2014, Kirill Yukhin wrote:
Hello Marc, Uroš,
On 10 Nov 21:33, Uros Bizjak wrote:
On Sun, Nov 9, 2014 at 5:26 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
and == for integer vectors of size 128. I was surprised not to find
_mm_cmplt_epi64 anywhere. Note that I can do
need to have
an if here. See the pedwarns at the beginning of finish_struct.
Do keywords like struct/union really require translation?
--
Marc Glisse
)
+++ ChangeLog.x86-intrinsics-ext(working copy)
@@ -1,10 +1,17 @@
+2014-11-11 Marc Glisse marc.gli...@inria.fr
+
+ * config/i386/avx2intrin.h (_mm256_cmpeq_epi8, _mm256_cmpeq_epi16,
+ _mm256_cmpeq_epi32, _mm256_cmpeq_epi64, _mm256_cmpgt_epi8,
+ _mm256_cmpgt_epi16
Hello,
here is the combined patch+ChangeLog. I'll run a last regtest just before
committing. Ok for trunk?
2014-11-12 Marc Glisse marc.gli...@inria.fr
gcc/
* config/i386/xmmintrin.h (_mm_add_ps, _mm_sub_ps, _mm_mul_ps,
_mm_div_ps, _mm_store_ss, _mm_cvtss_f32): Use vector
On Tue, 11 Nov 2014, Jonathan Wakely wrote:
+ templatetypename _Iterator, typename = __void_t
Is there a particular reason not to write void directly?
--
Marc Glisse
On Mon, 10 Nov 2014, Richard Biener wrote:
No extra includes required?
utility is already included in wide-int.h and rtl.h, should probably
move those.
--
Marc Glisse
that points to the
declaration. (I don't think the fix-it functions have been added yet)
--
Marc Glisse
Hello,
|^ of size 256 and 512. Regtested with 6/n.
2014-11-10 Marc Glisse marc.gli...@inria.fr
* config/i386/avx2intrin.h (_mm256_and_si256, _mm256_or_si256,
_mm256_xor_si256): Use vector extensions instead of builtins.
* config/i386/avx512fintrin.h (_mm512_or_si512
or after 7/n (avx2 version of
6/n).
Regtested with 5/n.
2014-11-10 Marc Glisse marc.gli...@inria.fr
* config/i386/emmintrin.h (_mm_cmpeq_epi8, _mm_cmpeq_epi16,
_mm_cmpeq_epi32, _mm_cmplt_epi8, _mm_cmplt_epi16, _mm_cmplt_epi32,
_mm_cmpgt_epi8, _mm_cmpgt_epi16
Hello,
this patch mechanically extends +-* for integer vectors of size 256 and
512 (the previous patch only handled 128).
Regtested together with the next patch.
2014-11-10 Marc Glisse marc.gli...@inria.fr
* config/i386/avxintrin.h (__v4du, __v8su, __v16hu, __v32qu):
New
that will be enough for gcc-5, we should discuss merging.
== abs min max can wait until gcc-6, possibly after getting some
feedback about +-*/|^.
2014-11-10 Marc Glisse marc.gli...@inria.fr
* config/i386/emmintrin.h (_mm_and_si128, _mm_or_si128, _mm_xor_si128):
Use vector extensions
were approved,
I'll use the first one if arm vectors are reworked in the same way as
aarch64 before the end of stage 1, and the other one if for some reason it
gets delayed.
2014-11-10 Marc Glisse marc.gli...@inria.fr
PR libstdc++/43622
gcc/cp/
* rtti.c (emit_support_tinfos
-def edges for SSA names
that are not single-use. Currently there are no patterns
that would cause any issues with that. */
(I am not opposing the patch, just trying to understand how things work
for when I'll propose new patterns)
--
Marc Glisse
;
vec d=~c;
vec e=c|d;
--
Marc Glisse
On Thu, 6 Nov 2014, Richard Biener wrote:
On Thu, 6 Nov 2014, Marc Glisse wrote:
On Thu, 6 Nov 2014, Richard Biener wrote:
+/* Try simple folding for X op !X, and X op X with the help
+ of the truth_valued_p and logical_inverted_value predicates. */
+(match truth_valued_p
+ @0
On Thu, 6 Nov 2014, Richard Biener wrote:
On Thu, 6 Nov 2014, Marc Glisse wrote:
On Thu, 6 Nov 2014, Richard Biener wrote:
On Thu, 6 Nov 2014, Marc Glisse wrote:
On Thu, 6 Nov 2014, Richard Biener wrote:
+/* Try simple folding for X op !X, and X op X with the help
On Wed, 5 Nov 2014, Ed Smith-Rowland wrote:
Like the uniform_on_sphere_distribution which is used inside, the
2-dimensional case uses rejection
Could you point out where in the code you are special-casing dimension 2?
Somehow I can't see it in the patch.
--
Marc Glisse
as r217114.
Thanks. Do you know if anyone is planning to port this patch to the arm
target (which IIRC has the same issue)? No pressure, this is just so I
know if I should ping the alternate __float128 patch or wait.
--
Marc Glisse
Ping?
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01808.html
On Sat, 18 Oct 2014, Marc Glisse wrote:
Hello,
this time, +-* for 128 bit integer vectors. I am using an unsigned type so
the compiler knows that we expect wrapping. I don't know why Intel's
description of mullo insists
PR60770 (the warning itself is PR60517).
2014-11-03 Marc Glisse marc.gli...@inria.fr
PR tree-optimization/60770
* tree-sra.c (clobber_subtree): New function.
(sra_modify_constructor_assign): Call it.
--
Marc GlisseIndex: gcc/testsuite/g++.dg/tree-ssa/pr60517.C
On Mon, 3 Nov 2014, Martin Jambor wrote:
On Mon, Nov 03, 2014 at 01:59:24PM +0100, Marc Glisse wrote:
Hello,
now that the update_address_taken patch is in, let me re-post the
SRA follow-up. With this patch, testcase pr60517.C (attached) has a
use of an undefined variable at the time
that.
--
Marc Glisse
On Mon, 3 Nov 2014, Marc Glisse wrote:
On Mon, 3 Nov 2014, Martin Jambor wrote:
I just applied your patch on top of trunk revision 217032 on my
Ah, that explains it, thanks. This patch is a follow-up to r217034. Still, I
didn't expect the ICE you are seeing by applying this patch to older
PROP_gimple_lvec before the second can_vec_perm_p (which must answer true
then).
I don't remember what the arg2 == op2 test is about, so I kept it. I also
didn't try to fix TREE_SIDE_EFFECTS handling, a quick test didn't trigger
that issue.
2014-11-03 Marc Glisse marc.gli...@inria.fr
* fold
On Fri, 31 Oct 2014, Richard Biener wrote:
On Sat, Oct 25, 2014 at 6:29 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Fri, 24 Oct 2014, Jeff Law wrote:
I'm starting to agree -- a later message indicated you wanted to drop the
unlink_stmt_vdef call and you wanted to avoid gsi_replace
On Sun, 2 Nov 2014, Marc Glisse wrote:
On Thu, 30 Oct 2014, Richard Biener wrote:
On Thu, 30 Oct 2014, Jakub Jelinek wrote:
On Thu, Oct 30, 2014 at 09:56:32AM +0100, Richard Biener wrote:
The following patch makes fold_ternary no longer make
VEC_PERMs valid for the target invalid
On Sun, 2 Nov 2014, Jakub Jelinek wrote:
On Sun, Nov 02, 2014 at 11:08:57AM +0100, Marc Glisse wrote:
@@ -14189,47 +14190,47 @@ fold_ternary_loc (location_t loc, enum t
return fold_build2_loc (loc, PLUS_EXPR, type,
const_binop (MULT_EXPR, arg0, arg1
]
On 10/17/14 14:41, Marc Glisse wrote:
Thinking about it some more, I don't think we should need any kind of
DCE here. The rewriting in update_ssa already does a form of forward
propagation that avoids generating dead assignments, the problem only
occurs if we explicitly introduce this new
what exactly a
clobber is guaranteed not to have (no histograms for instance? At least I
assumed it doesn't throw) so I may have kept some unnecessary calls when I
inlined gsi_replace. I'd be happy to remove any you feel is useless.
2014-10-26 Marc Glisse marc.gli...@inria.fr
PR
that we can get the proper warnings and errors. */
+ (if (!integer_zerop (@1))
+@0))
+ /* X % 1 is always zero. */
+ (simplify
+ (trunc_mod @0 integer_onep)
+ { build_zero_cst (type); }))
op is unused, you probably meant to replace trunc_mod with it.
--
Marc Glisse
On Wed, 22 Oct 2014, Petr Murzin wrote:
+ UINTVAL (op2) == 1 UINTVAL (tem))
With modes like V64QI around, it is better to replace 1 with
HOST_WIDE_INT_1U, though we are not consistent about it.
--
Marc Glisse
function, or a special syntax.
--
Marc Glisse
On Mon, 6 Oct 2014, François Dumont wrote:
* testsuite/25_algorithms/push_heap/complexity.cc: New.
This test is randomly failing in about 1% to 2% of cases.
--
Marc Glisse
701 - 800 of 1573 matches
Mail list logo