On Mon, 28 Jan 2013, Jakub Jelinek wrote:
On Mon, Jan 28, 2013 at 04:41:31PM +0100, Marc Glisse wrote:
On Mon, 28 Jan 2013, Jakub Jelinek wrote:
2013-01-28 Jakub Jelinek ja...@redhat.com
PR tree-optimization/56125
* tree-ssa-math-opts.c (gimple_expand_builtin_pow): Don't
Hello,
this message is to check that I am not doing something absurd and ask for
a bit of advice.
In the attached patch, I let SLP recognize vector loads/stores just like
it recognizes those in an array. It has a few issues: the cost of the
vectorized version is overestimated, the base
On Sun, 27 Jan 2013, Georg-Johann Lay wrote:
I found no 4.9 meta-bug in the 47 meta-bugs. You have th PR?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55996
--
Marc Glisse
()
- { _M_dispose(); }
+ {
+ _M_dispose();
+#ifdef __google_stl_debug_dangling_string
+ __builtin_memset(this, 0xcd, sizeof(*this));
+#endif
+ }
_CharT_alloc_type
_M_get_allocator()
--
Marc Glisse
On Thu, 3 Jan 2013, Tom Tromey wrote:
Marc == Marc Glisse marc.gli...@inria.fr writes:
Marc libcpp/
Marc* line-map.c (get_combined_adhoc_loc): Cast to extern C type.
Yucky.
Yes, there is a discussion of what is necessary for a real fix (and an
alternate hack) in the PR:
http
Ping
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00746.html
(I'll re-test since there have been changes around gmp.h inclusion)
On Tue, 11 Dec 2012, Marc Glisse wrote:
Hello,
this patch should help if we ever want to use sunCC to initiate a bootstrap,
though I didn't test with sunCC. Note
On Fri, 21 Dec 2012, Kai Tietz wrote:
2012-12-21 Kai Tietz
* config/os/mingw32/os_defines.h (_GLIBCXX_LLP64): Define if llp64
abi is used.
* config/os/mingw32-w64/os_defines.h: Likewise.
* libsupc++/cxxabi.h (__base_class_type_info): Change
type
a
hack, but the point here is only to help sunCC, making gcc extern
C-clean is a larger task...
Passes bootstrap+testsuite on x86_64-linux using the system's gcc
(graphite is enabled, don't know if this particular code is exercised).
2012-12-12 Marc Glisse marc.gli...@inria.fr
PR
(ix86_expand_vector_set) everywhere,
not just those scalarish operations.
So it would be good to have rth's opinion on this (svn blame seems to
indicate he is the one who chose to use vec_concat specifically for V2DF
instead of vec_merge).
--
Marc Glisse
On Fri, 7 Dec 2012, Michael Zolotukhin wrote:
By the way, if we decide to have one pattern for V4SF instructions and
another for V2DF, we could try to use recently introduced define_subst
here. It won't reduce number of actual patterns (I mean number of
patterns after iterators and subst
On Fri, 7 Dec 2012, Richard Henderson wrote:
On 2012-12-07 02:49, Marc Glisse wrote:
For 2-element vectors, vec_concat does seem more natural than
vec_merge. If we chose vec_merge as the canonical representation, we
should chose it for setting an element in a vector
(ix86_expand_vector_set
On Fri, 7 Dec 2012, Richard Henderson wrote:
On 2012-12-07 09:00, Marc Glisse wrote:
On Fri, 7 Dec 2012, Richard Henderson wrote:
On 2012-12-07 02:49, Marc Glisse wrote:
For 2-element vectors, vec_concat does seem more natural than
vec_merge. If we chose vec_merge as the canonical
On Fri, 7 Dec 2012, Richard Henderson wrote:
On 2012-12-07 09:12, Marc Glisse wrote:
but change ix86_expand_vector_set and others to generate vec_merge
and have only the vec_merge define_insn in sse.md? I guess it would
buy a large part of it. That's a pretty invasive change, I'll have to
try
.
Assuming they consistently use CRLF (I didn't look), wouldn't marking them
with svn:eol-style=CRLF be less problematic?
--
Marc Glisse
On Fri, 7 Dec 2012, Marc Glisse wrote:
On Fri, 7 Dec 2012, Richard Henderson wrote:
On 2012-12-07 09:12, Marc Glisse wrote:
but change ix86_expand_vector_set and others to generate vec_merge
and have only the vec_merge define_insn in sse.md? I guess it would
buy a large part of it. That's
exactly with the pass numbering
changes).
2012-12-06 Marc Glisse marc.gli...@inria.fr
* tree-pass.h (PROP_gimple_lvec): New.
* passes.c (dump_properties): Handle PROP_gimple_lvec.
(init_optimization_passes): Move pass_lower_vector.
* tree-vect-generic.c
Hello,
this comes on top of Jakub's patch from earlier today. The ce-index
checks only turn an ICE into an error: constexpr vector subscripts are not
handled yet, they are a bit more complicated.
2012-12-07 Marc Glisse marc.gli...@inria.fr
PR c++/53094
cp/
* tree.c
2012-12-04 Marc Glisse marc.gli...@inria.fr
PR target/54855
gcc/
* simplify-rtx.c (simplify_binary_operation_1) VEC_CONCAT: Replace
with VEC_MERGE.
* config/i386/sse.md (sse_vmplusminus_insnmode3): Rewrite
pattern.
* config/i386/i386-builtin
On Wed, 5 Dec 2012, Paolo Bonzini wrote:
Il 05/12/2012 15:22, Marc Glisse ha scritto:
+
+ /* The x86 back-end uses VEC_CONCAT to set an element in a V2DF, but
+ VEC_MERGE for scalar operations that preserve the other elements
+ of a vector. */
+ if (GET_CODE
On Mon, 3 Dec 2012, Uros Bizjak wrote:
On Mon, Dec 3, 2012 at 4:34 PM, Marc Glisse marc.gli...@inria.fr wrote:
However, looking a bit more into the usage cases for these patterns,
they are only used through intrinsics with _m128 operands. While your
proposed patch makes these patterns more
On Tue, 4 Dec 2012, Marc Glisse wrote:
Do you agree?
Like this ? (only tested on the new testcases, and then I'd need to ask Eric
his opinion)
2012-12-04 Marc Glisse marc.gli...@inria.fr
PR target/54855
gcc/
* simplify-rtx.c (simplify_binary_operation_1) VEC_CONCAT
On Mon, 3 Dec 2012, Uros Bizjak wrote:
On Sun, Dec 2, 2012 at 1:30 PM, Marc Glisse marc.gli...@inria.fr wrote:
here is a patch. If it is accepted, I'll extend it to other vm patterns
(mul, div, min, max are likely candidates, but I need to check the doc).
It
passed bootstrap+testsuite
On Sun, 2 Dec 2012, Uros Bizjak wrote:
On Sat, Dec 1, 2012 at 6:27 PM, Marc Glisse marc.gli...@inria.fr wrote:
here is a patch. If it is accepted, I'll extend it to other vm patterns
(mul, div, min, max are likely candidates, but I need to check the doc). It
passed bootstrap+testsuite
and RTL parts are independent, but the testcases need both.
bootstrap+testsuite on x86_64-linux. (for next stage1 I assume)
2012-12-02 Marc Glisse marc.gli...@inria.fr
PR target/43147
PR target/44551
gcc/
* simplify-rtx.c (simplify_binary_operation_1) VEC_SELECT
Hello,
here is a patch. If it is accepted, I'll extend it to other vm patterns
(mul, div, min, max are likely candidates, but I need to check the doc).
It passed bootstrap+testsuite on x86_64-linux.
2012-12-01 Marc Glisse marc.gli...@inria.fr
PR target/54855
gcc/
* config
Hello,
in PR50829, HJ Lu pointed me to this PR for which I already had a patch (I
hadn't submitted it because I didn't have a good use case for it).
bootstrap+testsuite on x86_64-linux.
2012-12-02 Marc Glisse marc.gli...@inria.fr
PR target/44551
gcc/
* simplify-rtx.c
On Sun, 14 Oct 2012, Marc Glisse wrote:
On Sun, 14 Oct 2012, Uros Bizjak wrote:
On Sat, Oct 13, 2012 at 10:52 AM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
this patch provides an alternate pattern to let combine recognize scalar
operations that preserve the high part of a vector
(match_operand:V2DF 1 register_operand 0,x)
(parallel [(const_int 0)]))
(match_operand:DF 2 nonimmediate_operand xm,xm))
(vec_select:DF (match_dup 1) (parallel [(const_int 1)]]
--
Marc Glisse
vectors in a constructor (the middle-end produces those, and I expect the
front-ends will too eventually).
Bootstrap+testsuite on x86_64-linux-gnu.
2012-11-29 Marc Glisse marc.gli...@inria.fr
PR c++/53094
gcc/
* fold-const.c (fold): Replace a CONSTRUCTOR with a VECTOR_CST
On Tue, 27 Nov 2012, Richard Biener wrote:
On Mon, Nov 12, 2012 at 2:31 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
this patch lets us fold a bit_field_ref of a constructor even when the
elements are vectors. Writing a testcase is not that convenient because of
the lack of a dead code
On Tue, 27 Nov 2012, Marc Glisse wrote:
On Tue, 27 Nov 2012, Richard Biener wrote:
It passes bootstrap+testsuite.
... on x86_64-linux-gnu, sorry for the lack of precision (default languages,
Xeon E5520, graphite enabled).
[...]
Boostrapped and tested on ... ?
Ok if bootstrap / testing
don't think the code is ready to properly expand it. I guess we'll have to
revisit this at some point.
Thus that hunk is ok as well.
Done, thanks.
--
Marc Glisse
;
+}
verify_gimple_* should have positive checks, thus, check that
if there are vector operands the comparison result should be a
vector. Not complaining about a vector comparison having a
boolean result.
I wasn't sure what that was supposed to look like, so I dropped it for
now.
--
Marc
be
ok.
2012-11-12 Marc Glisse marc.gli...@inria.fr
* fold-const.c (fold_ternary_loc) [BIT_FIELD_REF]: Handle
CONSTRUCTOR with vector elements.
* tree-ssa-propagate.c (valid_gimple_rhs_p): Handle CONSTRUCTOR
and BIT_FIELD_REF.
--
Marc GlisseIndex: gcc/fold
++98 instantiation that returns void.
That's going to happen in practice, isn't it? So do you mean to add the
abi tag to this unified function, for safety?
--
Marc Glisse
is still an ABI break. Is it for 4.8, or should it
wait until 4.9?
--
Marc Glisse
On Mon, 5 Nov 2012, Richard Sandiford wrote:
Marc Glisse marc.gli...@inria.fr writes:
* simplify-rtx.c (simplify_subreg): For vectors, create a VEC_SELECT.
Probably not helpful, sorry, but a subreg-vec_select transformation
feels like it's going in the wrong direction. Going from
Hello,
trying to make some progress on PR 53101, I wrote the attached patch
(it might be completely wrong for big endian, I don't know)
(it is also missing a check that it isn't a paradoxical subreg)
* simplify-rtx.c (simplify_subreg): For vectors, create a VEC_SELECT.
However, when I
On Sun, 4 Nov 2012, Marc Glisse wrote:
Hello,
trying to make some progress on PR 53101, I wrote the attached patch
(it might be completely wrong for big endian, I don't know)
(it is also missing a check that it isn't a paradoxical subreg)
* simplify-rtx.c (simplify_subreg
propagation doesn't really work for vectors
bootstrap+testsuite on x86_64-linux, some manual tests with -m32
-march=i486.
2012-11-01 Marc Glisse marc.gli...@inria.fr
PR middle-end/55001
gcc/
tree-vect-generic.c (expand_vector_condition): New function
to if(x0)(void)0.
2012-11-02 Marc Glisse marc.gli...@inria.fr
* tree-cfg.c (verify_gimple_comparison): Verify that vector
comparison returns a vector.
* fold-const.c (fold_unary_loc): Disable conversion optimization
for void type.
--
Marc GlisseIndex: gcc/fold
. It first scans the function being compiled to determine the
largest type that needs to be represented within that function and then it
uses some multiple of that size as it's definition of infinite.
I am currently using 4 for this value. However marc glisse claims that this
may be due to a bug
On Wed, 31 Oct 2012, Jakub Jelinek wrote:
On Tue, Oct 30, 2012 at 01:14:40PM +0100, Marc Glisse wrote:
On Tue, 30 Oct 2012, Marek Polacek wrote:
On Tue, Oct 30, 2012 at 08:05:13AM +0100, Marc Glisse wrote:
Hello,
one more optimization that needed help for vectors, it crashed on
(xy)0
temporaries on the stack but never used
for malloc'ed objects, that sounds good too.
Good luck with the useful wide_int work,
--
Marc Glisse
. The defaulted copy/move constructors you added are the
right solution for that.
Assuming you never copy a non-const lvalue or a const rvalue. The current
use seems ok, I just wanted to mention that it is rather fragile.
--
Marc Glisse
Hello,
one more optimization that needed help for vectors, it crashed on (xy)0.
Because of PR 55001, testcases are awkward to add (I could do a x86-only
one if needed).
bootstrap+testsuite.
2012-10-30 Marc Glisse marc.gli...@inria.fr
* fold-const.c
On Tue, 30 Oct 2012, Marek Polacek wrote:
On Tue, Oct 30, 2012 at 08:05:13AM +0100, Marc Glisse wrote:
Hello,
one more optimization that needed help for vectors, it crashed on
(xy)0. Because of PR 55001, testcases are awkward to add (I could
do a x86-only one if needed).
bootstrap+testsuite
On Mon, 29 Oct 2012, Richard Biener wrote:
On Sun, Oct 28, 2012 at 4:14 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
this patch lets some predicates on floating point constants answer true for
vectors, so optimizations are applied.
Tested bootstrap + testsuite (default languages).
Ok
directory `/tmp/testgcc/pristine/build'
make: *** [all] Error 2
--
Marc Glisse
Hello,
this patch lets some predicates on floating point constants answer true
for vectors, so optimizations are applied.
Tested bootstrap + testsuite (default languages).
2012-10-29 Marc Glisse marc.gli...@inria.fr
PR middle-end/55027
gcc/
* tree.c (real_zerop, real_onep
On Sun, 28 Oct 2012, Paolo Carlini wrote:
On 10/28/2012 04:46 PM, Paolo Carlini wrote:
On 10/28/2012 04:14 PM, Marc Glisse wrote:
Hello,
this patch lets some predicates on floating point constants answer true
for vectors, so optimizations are applied.
Great.
I wonder how are we doing
On Sun, 28 Oct 2012, Marc Glisse wrote:
[there are 4 real_*p that only differ by 1 character]
It is true that we could have a single function in tree.c:
bool real_intcstp (const_tree, int);
The helper function could even take a REAL_VALUE_TYPE as second
argument, so the non-inline part
On Sun, 28 Oct 2012, Paolo Carlini wrote:
I was writing something like the below.
I would move the one-liners (real_zerop, etc) to tree.h, but that looks
good, yes.
--
Marc Glisse
On Wed, 17 Oct 2012, Marc Glisse wrote:
Hello,
this patch adds support for vector conditions to the C++ front-end. Note that
the testcase currently only applies to x86. This is because there is work
remaining in the middle-end for the case where vector selection for this
vector mode
follows x86, what we are considering matches Power IIRC, and ARM only has
a bitwise selection (I only quickly glanced at all of these, I may have
read them wrong).
I am fine with both alternatives, but the choice is important...
--
Marc Glisse
.
templatetypename _Tp
struct common_type_Tp
-{ typedef _Tp type; };
+{ typedef typename decay_Tp::type type; };
(talking to myself)
I guess decay never has sfinae-type errors, so it doesn't matter whether
we have this typedef or derive from decay.
--
Marc Glisse
/data/repos/gcc/pristine/gcc/ira.c:4719
--
Marc Glisse
On Wed, 24 Oct 2012, Jason Merrill wrote:
On 10/19/2012 04:40 PM, Marc Glisse wrote:
So between the following:
a) x?y:z means (x0)?y:z
b) x?y:z means (x!=0)?y:z
c) x?y:z is rejected, only things like (x==t)?y:z are accepted
d) other
is the choice still b) ? That's an easy one, only 2
, etc).
(at a point, based on Richard's words but apparently not on his
suggestion, I was tempted to introduce a new boolean vector type, whose
only values are 0 and -1, but that seems a bit complicated and doesn't
answer whether x?y:z should mean x0 or x!=0)
--
Marc Glisse
On Mon, 15 Oct 2012, Richard Biener wrote:
On Fri, Oct 12, 2012 at 4:07 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Sat, 29 Sep 2012, Marc Glisse wrote:
1) it handles constant folding of vector comparisons,
2) it fixes another place where vectors are not expected
Here is a new version
(Adding Joseph in Cc: because we'll want the same behavior in C
afterwards. Conversation starts here:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01665.html )
On Thu, 18 Oct 2012, Marc Glisse wrote:
Clang's webpage says they support ?: for vector types, but my version (3.1)
rejects it, I'll
On Fri, 19 Oct 2012, Hans-Peter Nilsson wrote:
Looks like _U is one of those identifiers that should be
avoided:
[...]
What's the preferred replacement?
std::pair seems to use _U1 and _U2 rather than _U and _V.
--
Marc Glisse
On Wed, 17 Oct 2012, Jason Merrill wrote:
On 10/17/2012 10:30 PM, Marc Glisse wrote:
For each component of a vector type,
result[i] = if MSB of c[i] is set ? b[i] : a[i].
Curious. Do you know why they produce and expect -1 for true? It certainly
seems to be a deliberate design choice, so
Hello,
this patch adds support for vector conditions to the C++ front-end. Note
that the testcase currently only applies to x86. This is because there is
work remaining in the middle-end for the case where vector selection for
this vector mode is not provided by the target. There are also
On Wed, 17 Oct 2012, Jason Merrill wrote:
On 10/17/2012 12:56 PM, Marc Glisse wrote:
+ if (!COMPARISON_CLASS_P (arg1))
+ {
+ if (TYPE_UNSIGNED (TREE_TYPE (arg1_type)))
+ {
+ arg1_type = signed_type_for (arg1_type);
+ arg1 = convert
soon anyway, I just wanted to do
something while I was looking at this region of code.
Thanks,
--
Marc Glisse
On Sun, 14 Oct 2012, Uros Bizjak wrote:
On Sat, Oct 13, 2012 at 10:52 AM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
this patch provides an alternate pattern to let combine recognize scalar
operations that preserve the high part of a vector. If the strategy is all
right, I could do
), but probably
not as useful.
bootstrap+testsuite ok.
2012-10-13 Marc Glisse marc.gli...@inria.fr
PR target/54855
gcc/
* config/i386/sse.md (*sse2_vmplusminus_insnv2df3): New define_insn.
gcc/testsuite/
* gcc.target/i386/pr54855.c: New testcase.
--
Marc GlisseIndex
On Fri, 12 Oct 2012, Marc Glisse wrote:
Hello,
apparently, in the optimization that recognizes that {v[1],v[0]} is a
VEC_PERM_EXPR, I forgot to check that v is a 2-element vector... (not that
there aren't things that could be done if v has a different size, just not
directly a VEC_PERM_EXPR
On Fri, 12 Oct 2012, Jason Merrill wrote:
Let's use RO_ARROW_STAR to be more readable.
I now realize that I have no idea what RO_ARROW_PM was supposed to stand
for (Pointer to Member?), which proves that it was a bad name ;-)
OK with that change.
Thanks.
--
Marc Glisse
On Sat, 29 Sep 2012, Marc Glisse wrote:
1) it handles constant folding of vector comparisons,
2) it fixes another place where vectors are not expected
Here is a new version of this patch.
In a first try, I got bitten by the operator priorities in a b?c:d,
which g++ doesn't warn about
the bug)
Checking that v has the same type as the result seemed like the easiest
way, but there are many variations that could be slightly better or worse.
bootstrap+testsuite ok.
2012-10-02 Marc Glisse marc.gli...@inria.fr
PR tree-optimization/54915
gcc/
* tree-ssa
(VEC_COND_EXPR still requires a comparison as first argument) but that
shouldn't take too long to fix and it documents the intent.
2012-10-11 Marc Glisse marc.gli...@inria.fr
* doc/extend.texi (Vector Extensions): C++ improvements.
* doc/generic.texi (LSHIFT_EXPR, RSHIFT_EXPR
those
flags.
2012-10-11 Marc Glisse marc.gli...@inria.fr
PR testsuite/54868
* gcc.dg/tree-ssa/forwprop-22.c: Move ...
* gcc.dg/vect/nodump-forwprop-22.c: ... here. Adapt options.
--
Marc GlisseIndex: gcc.dg/vect/nodump-forwprop-22.c
On Thu, 11 Oct 2012, Richard Biener wrote:
On Thu, Oct 11, 2012 at 2:19 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
understanding the testsuite is hard, but this patch seems to work. The idea
is that vect_double and others don't tell that vectors are supported with
these options, just
into
it as a follow-up (the LHS doesn't have a location attached to it, so it
isn't just a matter of using error_at).
bootstrap+testsuite ok.
2012-10-12 Marc Glisse marc.gli...@inria.fr
PR c++/53055
gcc/c-family/
* c-common.h (enum ref_operator) [RO_ARROW_PM]: New.
gcc/cp
with an
SSA_NAME as first argument ;-)
bootstrap+testsuite ok.
2012-10-12 Marc Glisse marc.gli...@inria.fr
* optabs.c (vector_compare_rtx): Change prototype.
(expand_vec_cond_expr): Handle VEC_COND_EXPR whose first operand
is not a comparison.
* gimplify.c (gimplify_expr
On Mon, 8 Oct 2012, Richard Guenther wrote:
On Mon, Oct 8, 2012 at 11:34 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Mon, 8 Oct 2012, Richard Guenther wrote:
VEC_COND_EXPR is more complicated. We could for instance require that it
takes as first argument a vector of -1 and 0 (thus 0, !=0
, 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
operands can be canonicalized as vec_duplicate.
Actually, it is replacing vec_duplicate with vec_concat that would help.
Well, I'll see about that later.
Here is what I came up with, trying to follow your other advice (thanks a
lot!).
Passes bootstrap+testsuite.
2012-10-08 Marc Glisse
=scal-to-vec1.c'
2012-09-22 Marc Glisse marc.gli...@inria.fr
PR c++/54427
c/
* c-typeck.c: Include c-common.h.
(enum stv_conv): Moved to c-common.h.
(scalar_to_vector): Moved to c-common.c.
(build_binary_op): Adapt to scalar_to_vector's new prototype
23 entries like:
(define_insn_reservation bdver1_ssemuladd_256): Likewise
Next goal would be to further recognize some DPPD potential uses, but that
seems harder.
2012-10-09 Marc Glisse marc.gli...@inria.fr
gcc/
PR target/54400
* config/i386/i386.md (type attribute
constant like -1 can be huge.
--
Marc Glisse
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
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
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 marc.gli...@inria.fr wrote:
did you consider making the size of wide_int a template parameter, now
that we are using C++? All
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
On Wed, 3 Oct 2012, Gabriel Dos Reis wrote:
On Tue, Oct 2, 2012 at 1:53 PM, Marc Glisse marc.gli...@inria.fr wrote:
* include/c_std/cstdlib (abs(long long)): Define with
__builtin_llabs when we have long long.
(abs(__int128)): Define when we have __int128
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
after
the review (no point if the patch needs changing again).
2012-10-02 Marc Glisse marc.gli...@inria.fr
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
. I'll do a last check after the review
(no point if the patch needs changing again).
2012-10-02 Marc Glisse marc.gli...@inria.fr
PR libstdc++/54686
* include/c_std/cstdlib (abs(long long)): Define fallback whenever
we have long long but possibly not llabs.
(abs
On Tue, 2 Oct 2012, Gabriel Dos Reis wrote:
On Tue, Oct 2, 2012 at 3:57 AM, Marc Glisse marc.gli...@inria.fr 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
the compiler replace it with either (x0)?-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 marc.gli...@inria.fr wrote:
Or do you
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 Glisse marc.gli...@inria.fr
gcc/
* simplify
On Fri, 28 Sep 2012, Richard Guenther wrote:
On Fri, Sep 28, 2012 at 12:42 AM, Marc Glisse marc.gli...@inria.fr 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
had front-end
vec_cond_expr support to submit everything at once...
2012-09-27 Marc Glisse marc.gli...@inria.fr
* tree-cfg.c (verify_gimple_assign_ternary): Stricter check on
first argument of VEC_COND_EXPR.
* tree.c (truth_type_for): New function.
* tree.h
Hello,
RTL optimizers looks like a promising category, and Eric like a nice
maintainer for it, adding in Cc: ;-)
(I bothered Richard Sandiford last time)
On Tue, 11 Sep 2012, Marc Glisse wrote:
On Sun, 9 Sep 2012, Marc Glisse wrote:
Hello,
this patch lets the compiler try to rewrite
Adding an x86 maintainer in Cc:
On Tue, 11 Sep 2012, Marc Glisse wrote:
Hello,
any advice?
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00044.html
On Sun, 2 Sep 2012, Marc Glisse wrote:
Hello,
this patch passes bootstrap+testsuite. It is probably wrong in many ways,
but I don't know
it returns a single number. What we need is an
additional interface to return vectors.
Isn't the __generate interface good enough?
--
Marc Glisse
PS: mixed scalar-vector operations are posted here:
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01557.html
after that, C and C++ should be at the same
1301 - 1400 of 1573 matches
Mail list logo
