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
,
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
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
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
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
- 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
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
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
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
p; !HONOR_INFINITIES, then you don't even need
your REAL_VALUE_ISINF test.
--
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
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
don't apply
here...
--
Marc Glisse
e future?
It is confusing.
--
Marc Glisse
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
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
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
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
No :c on the first mult, so we don't actually handle A*C+B*C?
--
Marc Glisse
seems strange
to me, and likely not worth optimizing for.
--
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
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 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
* 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
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
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
. Maybe
(simplify
(bit_ior:c (bit_and:c (bit_not@2 @0) @1) (bit_not (bit_ior:c @0 @1)))
@2)
--
Marc Glisse
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
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
[-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, 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
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'
ed for a
__builtin_unreachable. Is it using the wrong macro?
--
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
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
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
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,
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
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
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
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
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
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
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
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
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
+ 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
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
, 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
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
_DIFF_EXPR more)
--
Marc Glisse
ld be
interested in looking at your approach.
--
Marc Glisse
7;restrict' when
inlining a function with attribute malloc?) and all that matters is
operator new.
--
Marc Glisse
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
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
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
(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
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
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, 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
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 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
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
with norm zero.
While there, do we want to also reject infinite norms?
I would have done: while (__sum < small || __sum > large)
but testing exactly for 0 and infinity seems good enough.
--
Marc Glisse
On Sat, 9 Aug 2014, Ulrich Drepper wrote:
On Sat, Aug 9, 2014 at 3:15 AM, Marc Glisse wrote:
While there, do we want to also reject infinite norms?
I would have done: while (__sum < small || __sum > large)
but testing exactly for 0 and infinity seems good enough.
I guess the squari
erate
points in a square until you get one in the disk). When the dimension
becomes higher, the probability that a point in the cube actually belongs
to the ball decreases, and it becomes cheaper to use a Gaussian.
--
Marc Glisse
x->2*x-1, if
__sq is not exactly 0, it must be between 2^-103 and 1 (for ieee
double), so I am not sure hypot gains that much (at least in my mind
hypot was mostly a gain close to 0 or infinity, but maybe it has more
advantages). It can only hurt speed though, so not a big issue.
--
Marc Glisse
ng, just making sure that's
what we want.
--
Marc Glisse
On Tue, 12 Aug 2014, Sylvestre Ledru wrote:
The patch fixes some typos found by Lintian, the Debian static analyzer.
Did you check them yourself? We end up with "these information" which
doesn't seem correct to me.
--
Marc Glisse
may add noexcept wherever you like.
It is constexpr that we can only add in GNU mode.
--
Marc Glisse
On Wed, 13 Aug 2014, Sylvestre Ledru wrote:
On 12/08/2014 19:38, Marc Glisse wrote:
On Tue, 12 Aug 2014, Sylvestre Ledru wrote:
The patch fixes some typos found by Lintian, the Debian static analyzer.
Did you check them yourself?
Sure (but I am not a native English speaker).
I am not a
On Wed, 13 Aug 2014, Paolo Carlini wrote:
... fixed with the below.
Could you please use __sq instead of recomputing it?
--
Marc Glisse
76: g++ (Debian 4.4.5-8) 4.4.5
pluto: g++ (Debian 4.9.1-1) 4.9.1
However, the "pluto" box also fails, and it's GCC is about up-to-date.
For your tests, I thought the sequence was:
checkout some revision of gcc
build a native gcc at this revision
use it to build a bunch of cro
.c to make it easier to add more builtins like strcpy.
Bootstrap+testsuite (really all languages) on x86_64-linux-gnu.
2014-08-18 Marc Glisse
PR tree-optimization/62112
gcc/
tree-ssa-alias.c (ref_may_alias_global_p, refs_may_alias_p,
ref_maybe_used_by_stmt_p): New
he vector makes the
dumps quite horrible (and wastes compilation time).
Bootstrap+testsuite on x86_64-linux-gnu.
2014-08-18 Marc Glisse
PR c++/54427
PR c++/57198
PR c++/58845
gcc/c-family/
* c-common.c (warn_logical_operator): Punt for vectors.
gcc/cp/
not return true with such a use_stmt, as far as I can see. As I
said, bootstrap+testsuite with an assert instead of 'return' didn't turn
up anything. I could keep it as a gcc_checking_assert (with a slight
update to the comment) if you like. Or did I miss a path in
dse_possible_dead_store_p?
Thanks,
--
Marc Glisse
Hello,
here is a new version of the patch which passed bootstrap+testsuite. I am
still removing the ref_maybe_used_by_stmt_p test, see the previous message
for a discussion.
2014-08-20 Marc Glisse
PR tree-optimization/62112
gcc/
* gimple-iterator.c (gsi_replace): Return
you only care that
@1 is non-zero. It is for comparisons like lt that the sign can change the
operation.
--
Marc Glisse
On Wed, 20 Aug 2014, Richard Biener wrote:
On Wed, 20 Aug 2014, Marc Glisse wrote:
On Wed, 20 Aug 2014, Richard Biener wrote:
Committed.
Also makes visible a desirable change I plan for if-exprs. They
should behave like outer ifs and allow us to write that series
of pattern as
(for op in
till in the testsuite and passed. The rest of the code
has changed quite a bit since then, it isn't that surprising if some test
becomes redundant. But if it makes you nervous, we could keep it as a
checking_assert, the cost should be negligible...
--
Marc Glisse
On Wed, 20 Aug 2014, Richard Biener wrote:
On Wed, Aug 20, 2014 at 9:14 AM, Marc Glisse wrote:
Hello,
here is a new version of the patch which passed bootstrap+testsuite. I am
still removing the ref_maybe_used_by_stmt_p test, see the previous message
for a discussion.
Looks good to me
On Wed, 20 Aug 2014, Marc Glisse wrote:
On Wed, 20 Aug 2014, Richard Biener wrote:
On Wed, Aug 20, 2014 at 9:14 AM, Marc Glisse wrote:
Hello,
here is a new version of the patch which passed bootstrap+testsuite. I am
still removing the ref_maybe_used_by_stmt_p test, see the previous message
On Wed, 20 Aug 2014, Richard Biener wrote:
On Wed, Aug 20, 2014 at 4:18 PM, Marc Glisse wrote:
On Wed, 20 Aug 2014, Richard Biener wrote:
- if (stmt != use_stmt
- && ref_maybe_used_by_stmt_p (use_stmt, gimple_assign_lhs
(stmt)))
- return;
-
I don't se
would be nice to copy-paste those comments, if the version in fold-const.c
is supposed to disappear.
(if that's planned for later, please ignore my message)
--
Marc Glisse
) was valid, @0 is the
bit_not, so it simplifies, but that was a pretty unreadable way to write
it, and I was scared that you had done it on purpose to help the machinery
guess the type. Glad to see that the simple version is ok.
--
Marc Glisse
On Fri, 22 Aug 2014, Tejas Belagod wrote:
On 28/06/14 11:25, Marc Glisse wrote:
On Mon, 23 Jun 2014, Tejas Belagod wrote:
Here is a patch that restructures neon builtins to use vector types based
on
standard base types. We previously defined arm_neon.h's neon vector
types(int8x8_t)
sg01695.html
I didn't check at what level you do the test, so I don't know if it can
see a TRUTH_NOT_EXPR for a vector or if it has already been replaced by
EQ_EXPR at that point.
--
Marc Glisse
On Fri, 22 Aug 2014, Jason Merrill wrote:
On 08/22/2014 03:24 PM, Marc Glisse wrote:
Note that there is a patch waiting for a review that makes us accept !v
for vector v:
Ah, indeed. I still think we might as well treat vectors the same as other
types here.
Ok, now that it is a conscious
Ping?
On Sat, 26 Jul 2014, Marc Glisse wrote:
Hello,
any comment on this patch?
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00769.html
On Tue, 10 Jun 2014, Marc Glisse wrote:
On Tue, 19 Mar 2013, Richard Henderson wrote:
I'm not fond of this, primarily because I believe the pa
type with
wrapping overflow, this is just doing the wrapping modulo 2^32.
--
Marc Glisse
4.9.2, I only expect to have to fix such things when moving to 5.0.
--
Marc Glisse
On Sun, 27 Jul 2014, Marc Glisse wrote:
On Thu, 10 Jul 2014, Richard Biener wrote:
--- gcc/tree-into-ssa.c (revision 212109)
+++ gcc/tree-into-ssa.c (working copy)
@@ -1831,26 +1831,38 @@ maybe_register_def (def_operand_p def_p,
{
tree def = DEF_FROM_PTR (def_p);
tree sym = DECL_P (def
27;ll just disable this optimization in the Go
frontend.
Shouldn't go use -fno-delete-null-pointer-checks by default then? That
should disable this optimization and others that rely on the same idea.
--
Marc Glisse
functions you move probably are better off in their new location, so you
can ignore my post.
--
Marc Glisse
[Discussion started in http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02472.html ]
On Wed, 30 Oct 2013, Marc Glisse wrote:
On Wed, 30 Oct 2013, Richard Biener wrote:
Btw, get_addr_base_and_unit_offset may also return an offsetted
MEM_REF (from &MEM [p_3, 17] for example). As we are intere
On Wed, 6 Nov 2013, Richard Biener wrote:
On Wed, Nov 6, 2013 at 1:19 PM, Marc Glisse wrote:
[Discussion started in
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02472.html ]
On Wed, 30 Oct 2013, Marc Glisse wrote:
On Wed, 30 Oct 2013, Richard Biener wrote:
Btw
this small bit of computation with double_int
when so much else assumes HWI is enough, but why not...
2013-11-09 Marc Glisse
Jeff Law
gcc/
* tree-ssa-alias.c (stmt_kills_ref_p_1): Use
ao_ref_init_from_ptr_and_size for builtins.
gcc/testsuite/
* gcc.dg/tre
Hello,
I am posting this patch to get some feedback on the approach. The goal is
to replace malloc+free with a stack allocation (a decl actually) when the
size is a small constant.
For testing, I highjacked the "leaf" attribute, but it isn't right, I'll
remove it from the list (not sure what
On Sun, 10 Nov 2013, Marc Glisse wrote:
I am posting this patch to get some feedback on the approach. The goal is to
replace malloc+free with a stack allocation (a decl actually) when the size
is a small constant.
A slightly updated version that handles abort and if(VAR==0) where VAR is
the
On Mon, 11 Nov 2013, Richard Biener wrote:
On Sun, Nov 10, 2013 at 4:27 PM, Marc Glisse wrote:
Hello,
I am posting this patch to get some feedback on the approach. The goal is to
replace malloc+free with a stack allocation (a decl actually) when the size
is a small constant.
For testing, I
401 - 500 of 1601 matches
Mail list logo
