ld be that we have the value of _2 and can keep
folding its uses.
--
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
*/
+ (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
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
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
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
(bad_alloc());
handler ();
}
where being in a loop may trigger opposite heuristics.
--
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
k, the 2 pointers are possibly
unrelated, so maybe the code emitted for an alias check should be
changed.
--
Marc Glisse
like the criterion would be a|(b&c) when the possible 1 bits of b
are included in the certainly 1 bits of a|c.
--
Marc Glisse
this particular transformation (don't change the patch
because of my comment), we just seem to be getting more and more uses of
single_use in match.pd, maybe at some point we need to revisit the meaning
of :s or introduce a stronger :S.
--
Marc Glisse
at's being worked on right now.
I've also added some extra tests to cover this new pattern. I've attached a
patch with my latest changes.
From: Richard Biener
Sent: Wednesday, July 28, 2021 2:59 AM
To: Victor Tong
Cc: Marc Glisse ; gcc-patches@gcc.gnu.org
Subject: Re: [EXT
IFN_FMIN bit_and bit_ior bit_xor)
+ (simplify (reduc (op @0 VECTOR_CST@1))
+(op (reduc:type @0) (reduc:type @1
I wonder if we need to test flag_associative_math for the 'plus' case,
or if the presence of IFN_REDUC_PLUS is enough to justify the possible
loss of precision.
--
Marc Glisse
eans :-(
(sorry for the broken thread, I was automatically unsubscribed because
mailman doesn't like greylisting)
--
Marc Glisse
red because the output is a single insn) but
not this new one, where it would not be ignored. That's not very
consistent.
--
Marc Glisse
s like it could be part of a separate
compiler flag or pragma, like C's FENV_ROUND can affect the rounding mode
in static initializers (of course C++ templates make pragmas less
convenient).
--
Marc Glisse
like a second
nop_convert:
(minus (nop_convert (plus:c (nop_convert @0) @1)) (nop_convert @0))
--
Marc Glisse
tends the 1/2/3 grouping to be able to group like (plus
(nop_convert2? @0) (convert2? @1))
so either both will be present or none (meaning that when grouping you
can choose the "cheaper"
test for one in case you know the conversions will be the same).
Nice.
--
Marc Glisse
use nop_convert for both (instead of
nop_convert1 and 2), but for constants that wouldn't work, so this looks
good.
--
Marc Glisse
that not
transforming when we don't see the comparison is likely on purpose. Plus,
if @5 was in a signed 1-bit type, it may look more like -1 than 1 and
break the transformation (is that forbidden as return type of a
comparion?).
--
Marc Glisse
E_P (TREE_TYPE (@0))
+&& !TYPE_UNSIGNED (TREE_TYPE (@0))
+&& TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (type))
Is there a risk that x is signed char (precision 8) and y is a vector with
8 elements?
--
Marc Glisse
On Wed, 26 May 2021, Prathamesh Kulkarni via Gcc-patches wrote:
The attached patch removes calls to builtins in vmul_n* (a, b) with __a * __b.
I am not familiar with neon, but are __a and __b unsigned here? Otherwise,
is vmul_n already undefined in case of overflow?
--
Marc Glisse
ense to try and generalize it a bit, say with
(cmp (nop_convert1? (bit_not @0)) CONSTANT_CLASS_P)
(scmp (view_convert:XXX @0) (bit_not @1))
(I still believe that it is a bad idea that SSA_NAMEs are strongly typed,
encoding the type in operations would be more convenient, but I think the
time for that choice has long gone)
--
Marc Glisse
On Fri, 4 Jun 2021, Hongtao Liu via Gcc-patches wrote:
On Tue, Jun 1, 2021 at 6:17 PM Marc Glisse wrote:
On Tue, 1 Jun 2021, Hongtao Liu via Gcc-patches wrote:
Hi:
This patch is about to simplify (view_convert:type ~a) < 0 to
(view_convert:type a) >= 0 when type is signed integer. S
es of each @i is not
reliable.
--
Marc Glisse
) & tree_nonzero_bits (@4)) == 0)
+ (mult @1
+{ wide_int_to_tree (type, wi::to_wide (@3) + wi::to_wide (@5)); })))
Could you explain how the convert helps exactly?
--
Marc Glisse
should be
unreachable and so (_M_value&1)==_M_value is then equivalent to _M_value>=0,
but is not a single use but two uses. I'll need to pattern match that case
specially.
Somewhere in RTL (_M_value&1)==_M_value is turned into (_M_value&-2)==0,
that could be worth doing already in GIMPLE.
--
Marc Glisse
though if X is signed, the
way GIMPLE represents types will add an inconvenient cast. And I think VRP
already manages to use the bit test to derive a range.
--
Marc Glisse
On Tue, 11 May 2021, Jakub Jelinek via Gcc-patches wrote:
On Thu, May 06, 2021 at 09:42:41PM +0200, Marc Glisse wrote:
We can probably do it in 2 steps, first something like
(for cmp (eq ne)
(simplify
(cmp (bit_and:c @0 @1) @0)
(cmp (@0 (bit_not! @1)) { build_zero_cst (TREE_TYPE (@0
On Fri, 14 May 2021, Jakub Jelinek via Gcc-patches wrote:
On Thu, May 06, 2021 at 09:42:41PM +0200, Marc Glisse wrote:
We can probably do it in 2 steps, first something like
(for cmp (eq ne)
(simplify
(cmp (bit_and:c @0 @1) @0)
(cmp (@0 (bit_not! @1)) { build_zero_cst (TREE_TYPE (@0
On Tue, 21 Nov 2023, Jonathan Wakely wrote:
CC Marc Glisse who added the relocation support. He might recall why
we use memmove when all uses are for newly-allocated storage, which
cannot overlap the existing storage.
Going back a bit:
https://gcc.gnu.org/pipermail/gcc-patches/2019-April
was optimized to just one call to calloc (someone broke that in gcc-10).
Using LTO on libsupc++ is related.
I don't know if we want to define "sane" operators new/delete, or just
have a flag that promises that we won't try to replace the default ones.
--
Marc Glisse
@3 @4))
(cnd @0 (op! @1 @3) (op! @2 @4)
?
The example given in the doc for the use of '!' is pretty close
@smallexample
(simplify
(plus (vec_cond:s @@0 @@1 @@2) @@3)
(vec_cond @@0 (plus! @@1 @@3) (plus! @@2 @@3)))
@end smallexample
--
Marc Glisse
o
fold X<=Y and if it folds to true then simplifies to Y. This way the
transformations would only need to be written for comparisons, not minmax.
--
Marc Glisse
On Sun, 4 Aug 2013, Gerald Pfeifer wrote:
On Sat, 13 Jul 2013, Marc Glisse wrote:
2013-07-14 Marc Glisse
gcc/cp/
* call.c (build_conditional_expr_1): Handle the case with 1 vector
and 2 scalars. Call save_expr before building a vector.
* typeck.c (cp_build_binary_op
On Thu, 8 Aug 2013, Joseph S. Myers wrote:
On Fri, 26 Jul 2013, Marc Glisse wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57324
(that is using llvm's sanitizer)
and for a first patch (unreviewed):
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01466.html
(started at http://gcc.gnu.o
st short/int. On x86, (lcompile for a vector of long, with lthat seems wrong.
--
Marc Glisse
On Mon, 26 Aug 2013, Joern Rennecke wrote:
Quoting Marc Glisse :
The issue seems larger than just short/int. On x86, (l
I don't understand what you mean here. Could you post the actual code
sample?
typedef long vl __attribute__((vector_size(16)));
void f(vl l){
(l(btw, my sentenc
Ping:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01624.html
and the related:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00230.html
--
Marc Glisse
On Fri, 30 Aug 2013, Richard Biener wrote:
On Sat, Jun 29, 2013 at 9:02 AM, Marc Glisse wrote:
Hello,
this patch changes the test deciding whether to fold "op d" with both
branches in (a ? b : c) op d. I don't know if the new test is right, it
gives what I expect on the new
On Fri, 30 Aug 2013, Richard Biener wrote:
On Sat, Jul 6, 2013 at 9:42 PM, Marc Glisse wrote:
First, the fold-const bit causes an assertion failure (building libjava) in
combine_cond_expr_cond, which calls:
t = fold_binary_loc (gimple_location (stmt), code, type, op0, op1);
and then
(attaching the latest version. I only added comments since regtesting it)
On Tue, 3 Sep 2013, Richard Biener wrote:
Btw, as for the patch I don't like that you basically feed everything into
fold. Yes, I know we do that for conditions because that's quite
important
and nobody has re-written th
a non-bootstrap compiler. I'll do more proper
testing when trunk bootstraps again.
2013-09-07 Marc Glisse
PR c++/19476
gcc/
* fold-const.c (tree_expr_nonzero_warnv_p): Handle operator new.
* tree-vrp.c (gimple_stmt_nonzero_warnv_p, stmt_interesting_for_vr
On Sat, 7 Sep 2013, Basile Starynkevitch wrote:
On Sat, 2013-09-07 at 12:33 +0200, Marc Glisse wrote:
Hello,
this patch teaches the compiler that operator new, when it can throw,
isn't allowed to return a null pointer. Note that it doesn't work for
placement new (that one may
On Sat, 7 Sep 2013, Marc Glisse wrote:
this patch teaches the compiler that operator new, when it can throw, isn't
allowed to return a null pointer. Note that it doesn't work for placement new
(that one may have to be handled in the front-end or the inliner),
Placement new is a
On Sat, 7 Sep 2013, Gabriel Dos Reis wrote:
On Sat, Sep 7, 2013 at 11:42 AM, Marc Glisse wrote:
On Sat, 7 Sep 2013, Marc Glisse wrote:
this patch teaches the compiler that operator new, when it can throw,
isn't allowed to return a null pointer. Note that it doesn't work for
pla
On Sat, 7 Sep 2013, Mike Stump wrote:
On Sep 7, 2013, at 3:33 AM, Marc Glisse wrote:
this patch teaches the compiler that operator new, when it can throw, isn't
allowed to return a null pointer.
You sure:
@item -fcheck-new
@opindex fcheck-new
Check that the pointer returned by
On Sat, 7 Sep 2013, Mike Stump wrote:
On Sep 7, 2013, at 12:37 PM, Gabriel Dos Reis
wrote:
On Sat, Sep 7, 2013 at 2:27 PM, Marc Glisse wrote:
On Sat, 7 Sep 2013, Mike Stump wrote:
On Sep 7, 2013, at 3:33 AM, Marc Glisse wrote:
this patch teaches the compiler that operator new, when
On Sat, 7 Sep 2013, Mike Stump wrote:
On Sep 7, 2013, at 12:27 PM, Marc Glisse wrote:
Now flag_check_new should probably disable this optimization…
Yes, this why my point.
Ok, here it is (again, no proper testing until bootstrap is fixed)
2013-09-07 Marc Glisse
PR c++/19476
On Sat, 7 Sep 2013, Marc Glisse wrote:
On Sat, 7 Sep 2013, Mike Stump wrote:
Can this throw:
void *operator new (long unsigned int s) {
return 0;
}
? Is this allowed to return 0?
I think using this function is illegal. It isn't marked noexcept, so it isn't
allowed to return 0
On Mon, 9 Sep 2013, Richard Biener wrote:
On Sat, Sep 7, 2013 at 11:00 PM, Marc Glisse wrote:
On Sat, 7 Sep 2013, Mike Stump wrote:
On Sep 7, 2013, at 12:27 PM, Marc Glisse wrote:
Now flag_check_new should probably disable this optimization…
Yes, this why my point.
Ok, here it is
I have now tested bootstrap+testsuite and there was no regression.
2013-09-07 Marc Glisse
PR c++/19476
gcc/
* fold-const.c (tree_expr_nonzero_warnv_p): Handle operator new.
* tree-vrp.c (gimple_stmt_nonzero_warnv_p, stmt_interesting_for_vrp):
Likewise
Any other comments on this patch?
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00129.html
On Tue, 3 Sep 2013, Marc Glisse wrote:
(attaching the latest version. I only added comments since regtesting it)
On Tue, 3 Sep 2013, Richard Biener wrote:
Btw, as for the patch I don't like tha
Ping
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01381.html
On Fri, 23 Aug 2013, Marc Glisse wrote:
On Sun, 4 Aug 2013, Gerald Pfeifer wrote:
On Sat, 13 Jul 2013, Marc Glisse wrote:
2013-07-14 Marc Glisse
gcc/cp/
* call.c (build_conditional_expr_1): Handle the case with 1
Hello,
this patch passes bootstrap+testsuite. The guarantees given by the
standard on allocators are a bit weird, but I see there is already DR2016
taking care of it.
2013-09-14 Marc Glisse
PR libstdc++/58338
* include/bits/stl_vector.h
(_Vector_impl::_Vector_impl
ay want to keep some consistency. I can do vector in the other
modes next if you want.
--
Marc Glisse
013-09-15 Marc Glisse
PR libstdc++/58338
* include/bits/stl_vector.h
(_Vector_impl::_Vector_impl(_Tp_alloc_type const&),
_Vector_impl::_Vector_impl(_Tp_alloc_type&&),
_Vector_impl::_M_swap_data,
_Vector_base::_Vector_base
On Mon, 16 Sep 2013, Paolo Carlini wrote:
On 09/15/2013 11:12 AM, Marc Glisse wrote:
I had to separate the constructor that takes an allocator from the default
constructor in debug/profile, since in release the noexcept only applies to
one of them (and the testsuite asserts that release and
On Mon, 16 Sep 2013, Jonathan Wakely wrote:
Are you sure the noexcept on the destructors is useless?
Ok, I am putting it back in.
--
Marc Glisse
New version that passed testing.
2013-09-16 Marc Glisse
PR libstdc++/58338
* include/bits/stl_vector.h (vector::vector(),
vector::vector(const allocator_type&)): Merge.
(_Vector_impl::_Vector_impl(_Tp_alloc_type const&),
_Vector_impl::_Vec
Nobody has expressed concern for a week, so it may be worth doing an
official review ;-)
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00676.html
On Mon, 9 Sep 2013, Marc Glisse wrote:
I have now tested bootstrap+testsuite and there was no regression.
2013-09-07 Marc Glisse
PR c
same wrapper is used for several containers, so unless we change all
containers at once it can't stay consistent.
Bootstrap+testsuite ok.
2013-09-18 Marc Glisse
PR libstdc++/58338
* include/bits/list.tcc (_List_base::_M_clear, list::erase): Mark as
On Wed, 18 Sep 2013, Paolo Carlini wrote:
On 09/17/2013 08:44 PM, Marc Glisse wrote:
after vectors, lists. I didn't touch the throw we were discussing earlier
today for now. There will be an inconsistency with debug list iterators
because they use a general wrapper:
- I would need Franço
changing this
with my patch.
I replaced throw with abort in list, as discussed, and thus removed the
corresponding testcase.
bootstrap+testsuite ok.
2013-09-19 Marc Glisse
PR libstdc++/58338
* include/bits/stl_iterator.h (__normal_iterator) [__normal_iterator
On Wed, 18 Sep 2013, Paolo Carlini wrote:
On 09/18/2013 05:51 PM, Marc Glisse wrote:
In debug array, we already have throw in noexcept functions, but if I
understand correctly it is only because of syntax limitations for constexpr
functions and aborts before throwing, although the use of
tinct.
bootstrap+testsuite ok.
2013-09-19 Marc Glisse
PR libstdc++/58338
* include/bits/stl_tree.h (_Rb_tree_node_base) [_S_minimum, _S_maximum]:
Mark as noexcept.
(_Rb_tree_iterator) [_Rb_tree_iterator, operator*, operator->,
operator++, operator--,
On Fri, 20 Sep 2013, Paolo Carlini wrote:
On 09/20/2013 09:46 AM, Marc Glisse wrote:
Hello,
for basic_string, I tried not to add lies about exceptions, but I didn't
remove existing ones.
Of course we should not have lies, I thought we didn't, besides maybe special
cases having to d
wanting to introduce -fno-abort -fno-terminate flags to turn those 2 calls
into __builtin_unreachable).
Note that I am still a proponent of noexcept(auto), if it can't be the
default. If someone feels like implementing it as an extension, we could
use it in the library.
--
Marc Glisse
ests
necessary for a submission?
http://gcc.gnu.org/contribute.html has an outdated section on testing. It
mentions that you should do a bootstrap for a change to the C front-end
(should also be for the C++ front-end and I guess libstdc++ even if it
isn't used much inside gcc).
--
Marc Glisse
Hello,
this patch was tested on x86_64 with a bootstrap and a simple make -k
check, without regression. Note that it doesn't completely fix 56166, it
merely admits that we may currently throw and avoids turning that into
std::terminate.
2013-09-24 Marc Glisse
PR libstdc++/
On Mon, 23 Sep 2013, Paolo Carlini wrote:
On 9/23/13 10:55 AM, Marc Glisse wrote:
Hello,
this patch was tested on x86_64 with a bootstrap and a simple make -k
check, without regression. Note that it doesn't completely fix 56166, it
merely admits that we may currently throw and a
gainst your proposal of
having the move-constructor identical to the copy-constructor in that case.
In 4.9.x some targets, not Linux, would benefit from it.
Sorry.
--
Marc Glisse
Hello,
this was only minimally tested since trunk is broken at the moment. There
don't seem to be specific tests for the existing functors, so a couple
tests for the new specializations seem good enough.
2013-09-25 Marc Glisse
* include/bits/stl_function.h: Include fo
ltype(auto) for the return type, as that would
disable sfinae, it is a bad sign when the standard turns its nose up at
its own dog food...)
--
Marc Glisse
It isn't a front-end patch, but it is still a C++ patch, maybe Jason will
have comments? Anyone else?
On Mon, 16 Sep 2013, Marc Glisse wrote:
Nobody has expressed concern for a week, so it may be worth doing an official
review ;-)
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00676.htm
On Wed, 2 Oct 2013, Jakub Jelinek wrote:
On Mon, Sep 09, 2013 at 10:49:40PM +0200, Marc Glisse wrote:
--- fold-const.c(revision 202413)
+++ fold-const.c(working copy)
@@ -16171,21 +16171,31 @@ tree_expr_nonzero_warnv_p (tree t, bool
case MODIFY_EXPR:
case BIND_EXPR
Hello,
I don't understand why those 2 files differ by more than 1 extra argument,
so I am changing that.
Bootstrap and testsuite on x86_64.
2013-10-03 Marc Glisse
* libsupc++/del_op.cc (operator delete): Don't test for 0 before free.
* libsupc++/del_opnt.cc (f
New version after Jakub's comment, bootstrap and testsuite on x86_64.
2013-10-03 Marc Glisse
PR c++/19476
gcc/
* calls.c (alloca_call_p): Use get_callee_fndecl.
* fold-const.c (tree_expr_nonzero_warnv_p): Handle operator new.
* tree-
On Wed, 2 Oct 2013, Jason Merrill wrote:
On 10/02/2013 08:33 AM, Marc Glisse wrote:
+ if (flag_delete_null_pointer_checks && !flag_check_new
You can't use flag_check_new in language-independent code without moving it
from c.opt to common.opt.
Thanks, that makes sens
On Wed, 2 Oct 2013, Christopher Jefferson wrote:
On 2 October 2013 13:28, Marc Glisse wrote:
Hello,
I don't understand why those 2 files differ by more than 1 extra argument,
so I am changing that.
Bootstrap and testsuite on x86_64.
2013-10-03 Marc Glisse
* libsupc++/del_
On Fri, 28 Sep 2012, Richard Guenther wrote:
On Fri, Sep 28, 2012 at 12:42 AM, Marc Glisse wrote:
Hello,
I have been experimenting with generating VEC_COND_EXPR from the front-end,
and these are just a couple things I noticed.
1) optabs.c requires that the first argument of vec_cond_expr be
g.
When expanding vcond, they can do the comparison as they like. When
expanding an isolated comparison, I expect they have to expand it as
vcond(asomething.
2012-10-01 Marc Glisse
gcc/
* tree.c (integer_truep): New function.
* tree.h (integer_truep): Declare.
* t
here is also the vec_duplicate case (I should try
to replace vec_duplicate with vec_concat in simplify-rtx to see what
happens...). Still, the identity case is nice to have.
Thanks for your comments.
bootstrap+testsuite on x86_64-linux-gnu with default languages.
2012-09-09 Marc G
On Mon, 1 Oct 2012, Eric Botcazou wrote:
2012-09-09 Marc Glisse
gcc/
* simplify-rtx.c (simplify_binary_operation_1) :
Detect the identity.
: Handle VEC_SELECTs from the same vector.
gcc/testsuite/
* gcc.target/i386/vect-rebuild.c: New testcase.
OK if you
e front-end would generate
for a
That said, until we are sure what semantics we want here (forwprop
for example doesn't look at 'comparisons' but operations on special
values and types) I'd prefer to not introduce integer_truep ().
I completely agree that defining the semantics comes first :-)
--
Marc Glisse
do a last check after
the review (no point if the patch needs changing again).
2012-10-02 Marc Glisse
PR libstdc++/54686
* include/c_std/cstdlib (abs(long long)): Define fallback whenever
we have long long but possibly not llabs.
(abs(long long)): Use llabs
sh/newlib. I'll do a last check after the review
(no point if the patch needs changing again).
2012-10-02 Marc Glisse
PR libstdc++/54686
* include/c_std/cstdlib (abs(long long)): Define fallback whenever
we have long long but possibly not llabs.
(abs(l
On Tue, 2 Oct 2012, Gabriel Dos Reis wrote:
On Tue, Oct 2, 2012 at 3:57 AM, Marc Glisse wrote:
(Forgot libstdc++...)
Hello,
here is the patch from PR54686. Several notes:
* I'll have to ask experts if std::abs(unsigned) (yes, a weird thing to do,
but still) is meant to return a d
ave an llabs or not),
and let the compiler replace it with either (x<0)?-x:x or a library call
(I assume it never does that unless it has seen a corresponding
declaration)?
Note that I am happy to let you take over this PR if you like.
--
Marc Glisse
consider a compile-time test
superior to a configure test. The macro __SIZEOF_INT128__ was invented
precisely for this purpose. Yes, that's just more whining ;-)
On Tue, 2 Oct 2012, Gabriel Dos Reis wrote:
On Tue, Oct 2, 2012 at 8:07 AM, Marc Glisse wrote:
Or do you mean:
always
On Wed, 3 Oct 2012, Gabriel Dos Reis wrote:
On Tue, Oct 2, 2012 at 1:53 PM, Marc Glisse wrote:
* include/c_std/cstdlib (abs(long long)): Define with
__builtin_llabs when we have long long.
(abs(__int128)): Define when we have __int128.
This change is OK
Thanks
acro so it
doesn't show. I am asking because in vrp I do some arithmetic that
requires 2*N+1 bits where N is the size of double_int.
--
Marc Glisse
On Wed, 3 Oct 2012, Mike Stump wrote:
On Oct 3, 2012, at 1:47 PM, Marc Glisse wrote:
did you consider making the size of wide_int a template parameter, now
that we are using C++? All with a convenient typedef or macro so it
doesn't show. I am asking because in vrp I do some arithmetic
On Thu, 4 Oct 2012, Kenneth Zadeck wrote:
On 10/04/2012 09:17 AM, Marc Glisse wrote:
On Wed, 3 Oct 2012, Mike Stump wrote:
On Oct 3, 2012, at 1:47 PM, Marc Glisse wrote:
did you consider making the size of wide_int a template parameter, now
that we are using C++? All with a convenient
wrapping multiplication code in vrp works with a pair of
double_int, so it should keep working with a pair of wide_int. I see now
why wide_int doesn't allow to simplify the code, but it doesn't have to
break.
--
Marc Glisse
small" constant like -1 can be huge.
--
Marc Glisse
he MSB of each element. So it is still time to change that if
you want to. But if we want to change it, I think it should happen now
before even more vector code gets in (not particularly my patches, I am
thinking of cilk and others too).
Ok, that's long enough, I need to send it now...
--
Marc Glisse
Ping
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01557.html
On Fri, 21 Sep 2012, Marc Glisse wrote:
Hello,
this patch adds mixed scalar-vector operations to the C++ front-end. It also
adds a few operators to the C front-end (comparisons in particular). This
patch is mostly an import from
On Fri, 5 Oct 2012, Jason Merrill wrote:
On 09/21/2012 02:32 PM, Marc Glisse wrote:
+ gcc_assert (TREE_CODE (type0) == VECTOR_TYPE
+ || TREE_CODE (type1) == VECTOR_TYPE);
+ switch (code)
+{
+ case RSHIFT_EXPR:
+ case LSHIFT_EXPR:
+ if (TREE_CODE (type0
parison and make gimple checking reflect that?
(seems sad, but at least that would tell me what I can/can't do)
By the way, since we are documenting comparisons as returning 0 and -1,
does that bring back the integer_truep predicate?
--
Marc Glisse
1 - 100 of 1601 matches
Mail list logo
