On Tue, 24 Sep 2019, Jonathan Wakely wrote:
On 24/09/19 09:57 +0100, Jonathan Wakely wrote:
On 23/09/19 19:39 +0200, Marc Glisse wrote:
On Mon, 23 Sep 2019, Jonathan Wakely wrote:
If __index_type is a smaller type than size_t, then the result of
size_t(__index_type(-1)) is not equal to
Ping https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00808.html
with one more potential reviewer in Cc.
On Wed, 11 Sep 2019, Marc Glisse wrote:
Ping
On Tue, 3 Sep 2019, Marc Glisse wrote:
On Fri, 2 Aug 2019, Marc Glisse wrote:
Ping
On Tue, 16 Jul 2019, Marc Glisse wrote:
Adding a C
easily mix some functions compiled at -O3 with other
functions compiled at -O2 and thus using a different param?
--
Marc Glisse
es to make it to work.
If you want to cheat and consider it as a test only for FRE / DCE,
__attribute__((flatten)) on f should work. But it can be useful to keep it
in a state where it still tests the inliner as well...
--
Marc Glisse
if (opt_for_fn (n->decl, optimize) >= 3)
? It doesn't matter, just looks surprising.
--
Marc Glisse
; instead of "does this interval contain the
value 0". I naively believe there shouldn't even be any API for the first
question. Or if pointers really only have 2 possible intervals (besides
varying and undefined), aka [0,0] and ~[0,0], using intervals seems like
overkill for them...
--
Marc Glisse
c_limits says here is not very meaningful, and users can't rely on
it 100%.
By default, numeric_limits gives yes if IEC support exists on the
platform. The change would sometimes make it say no, when we know for sure
that this support is not enabled at the beginning of the translation unit.
Why not...
--
Marc Glisse
i integer_zerop) to just @i before reaching this, but it
doesn't make the transformation wrong.
Same remark as above for TYPE_OVERFLOW_UNDEFINED, is that for the sake of
-fsanitize=pointer-overflow?
--
Marc Glisse
tr + 255 or ptr - 1?
(pointer_plus ptr 255) would mean ptr - 1 on a platform where the second
argument of pointer_plus has size 1 byte.
Do note that I am not a reviewer, what I say isn't final.
--
Marc Glisse
2020-06-04 Marc Glisse
* include/std/optional (optional()): Explicitly define it.
(I don't currently have a setup that would enable me to commit anything. I'll
try to fix it eventually, but likely not so soon)
--
Marc Glissediff --git a/libstdc++-v3/include/std/optional b/li
On Thu, 4 Jun 2020, Ville Voutilainen wrote:
On Thu, 4 Jun 2020 at 01:52, Marc Glisse wrote:
Hello,
is there any drawback to the attached patch? It changes the code generated for
I don't get it. The noexceptness of the defaulted default constructor
should be a computation
o
years.
What I feared was some regression where it would yield worse code in some
cases, or lose some property (not guaranteed by the standard) like
triviality (to the point of affecting the ABI?), but I couldn't see
anything like that happening.
(we still have PR86173 causing unnecessary
ly
with some protection against optimizations? Ah, no, actual constructors
are fine, it is only the inlined initialization that happens with the
defaulted constructor that zeroes things.
--
Marc Glisse
On Thu, 4 Jun 2020, Ville Voutilainen wrote:
On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote:
Maybe create a buffer, fill it with some non-zero values (-1?), then call
placement new, and read some value in the middle of the buffer, possibly
with some protection against optimizations? Ah, no
On Thu, 4 Jun 2020, Ville Voutilainen wrote:
On Thu, 4 Jun 2020 at 11:53, Marc Glisse wrote:
On Thu, 4 Jun 2020, Ville Voutilainen wrote:
On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote:
Maybe create a buffer, fill it with some non-zero values (-1?), then call
placement new, and read some
On Thu, 4 Jun 2020, Richard Biener wrote:
On Thu, Jun 4, 2020 at 11:34 AM Ville Voutilainen via Gcc-patches
wrote:
On Thu, 4 Jun 2020 at 11:53, Marc Glisse wrote:
On Thu, 4 Jun 2020, Ville Voutilainen wrote:
On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote:
Maybe create a buffer, fill
Or am I missing some cases?
(I didn't look at the patch and if that's the right condition, just
randomly commenting on this line)
--
Marc Glisse
d then extending it to non-constants)?
I wonder if this makes
/* ~(~X - Y) -> X + Y and ~(~X + Y) -> X - Y. */
useless.
--
Marc Glisse
On Sat, 12 Dec 2020, Jakub Jelinek via Gcc-patches wrote:
On Sat, Dec 12, 2020 at 01:25:39PM +0100, Marc Glisse wrote:
On Sat, 12 Dec 2020, Jakub Jelinek via Gcc-patches wrote:
This patch adds the ~(X - Y) -> ~X + Y simplification requested
in the PR (plus also ~(X + C) -> ~X + (-
g the same directory for
linking should imply using the same directory for includes.
--
Marc Glisse
= 0
Yes you can. It is illegal to use either expression if ptr_a and ptr_b do
not point inside the same object, and objects are not allowed to be larger
than half the address space.
Comparing arbitrary pointers (not in the same object) is done with
(uintptr_t)ptr_a > (uintptr_t)ptr_b.
--
Marc Glisse
trapped and tested on aarch64-none-linux-gnu.
OK for master ?
Cheers,
Przemyslaw
gcc/ChangeLog:
PR tree-optimization/94880
* match.pd (A | B) - B -> (A & ~B): New simplification.
gcc/testsuite/ChangeLog:
PR tree-optimization/94880
* gcc.dg/tree-ssa/pr94880.c: New Test.
--
Marc Glisse
ne-linux-gnu.
OK for master ?
Cheers,
Przemyslaw
gcc/ChangeLog:
PR tree-optimization/94880
* match.pd (A | B) - B -> (A & ~B): New simplification.
gcc/testsuite/ChangeLog:
PR tree-optimization/94880
* gcc.dg/tree-ssa/pr94880.c: New Test.
--
Marc Glisse
he change can be seen as a
simplification and should be pushed to master. It regtests fine.
2020-06-20 Marc Glisse
* include/bits/stl_algo.h (__includes): Simplify the code.
(as with the patch for std::optional, I still haven't worked on my ssh key
issue and cannot currently pus
rtain point.
What is this point supposed to be? If I understood you right,
106t.thread1 is already too late - why is it so?
Small remark: shouldn't __atomic_add_const be marked with the
always_inline attribute, since it isn't usable when it isn't inlined?
--
Marc Glisse
b_c_p==true (including the asm, here). Otherwise, any _b_c_p can be
optimized to true, because for a boolean
b is the same as b ? true : false
__builtin_constant_p(b ? true : false) would be the same as b ?
__builtin_constant_p(true) : __builtin_constant_p(false), i.e. true.
It is too bad we don't have any optimization pass using ranges between IPA
and thread1, that would have gotten rid of the comparisons, and hence the
temptation to thread. Adding always_inline on atomic_add (or flatten on
the caller) does help: EVRP removes the comparisons.
Do you see a way forward without changing what thread1 does or declaring
the testcase as unsupported?
--
Marc Glisse
pass-through on the
arguments and the result.
--
Marc Glisse
could only happen in "#pragma fenv_access off" regions, which
seems to imply that it would be the front-end's responsibility (although
it would need help from the back-end to know the default value to fold
to).
--
Marc Glisse
lt; MIN(X, Y) -> false
So, the result will be true for GE_EXPR and LE_EXPR and false otherwise.
Is that true even if X is NaN?
It may be hard to hit a situation where this matters though, if we honor
NaN, we don't build MAX_EXPR (which is unspecified).
--
Marc Glisse
ld succeed if either overflow
is undefined or if VRP can prove that no overflow is happening.
Of course that's all ideas for later, refactoring belongs in the second or
third patch using a feature, not the first one :-)
--
Marc Glisse
y try to see a pattern
in the list of types that work)
--
Marc Glisse
(you would somehow need one pointer close to 0
and the other close to 2^32 so they end up close modulo 2^32, but that
would require @2+@1 to overflow which means the loop will never run that
far anyway).
But we are still lying and taking a risk that some other optimization
will trust us. (I am
On Wed, 1 Aug 2018, Martin Liška wrote:
On 07/27/2018 02:38 PM, Marc Glisse wrote:
On Fri, 27 Jul 2018, Martin Liška wrote:
So answer is yes, the builtin can be then removed.
Good, thanks. While looking at how widely it is going to apply, I noticed that the
default, throwing operator new
On Wed, 1 Aug 2018, Martin Liška wrote:
On 08/01/2018 02:25 PM, Marc Glisse wrote:
On Wed, 1 Aug 2018, Martin Liška wrote:
On 07/27/2018 02:38 PM, Marc Glisse wrote:
On Fri, 27 Jul 2018, Martin Liška wrote:
So answer is yes, the builtin can be then removed.
Good, thanks. While looking
_mm_move_ss.
--
Marc Glisse
7;t have a strong opinion on what the best approach is.
--
Marc Glisse
On Sun, 5 Aug 2018, MCC CS wrote:
this patch reduces calls to logarithm functions by
merging log a + log b => log a*b and
this makes sense.
+ /* x * logN(a) + y * logN(b) -> x * y * logN(a * b). */
this on the other hand... Can you explain the math?
--
Marc Glisse
m in the
minority...
--
Marc Glisse
On Sun, 5 Aug 2018, MCC CS wrote:
Besides, if you think optimizing
/* logN(a) + logN(b) -> logN(a * b) */
would be enough, without the coefficients,
here's a simpler patch:
Index: gcc/match.pd
===
--- gcc/match.pd(revision 2633
at gcc immediately replaces ~(align - 1) with -align. It does it
even if you compute align-1 on the previous line and write (sz+X)&~X in
the hope of sharing the subtraction.
--
Marc Glisse
On Fri, 17 Aug 2018, Jonathan Wakely wrote:
On 17/08/18 19:28 +0200, Marc Glisse wrote:
On Mon, 13 Aug 2018, Jonathan Wakely wrote:
Thanks to Lars for the suggestions.
* libsupc++/new_opa.cc (operator new(size_t, align_val_t)): Use
__is_pow2 to check for valid alignment
nt s)
+{
+ return ~(~(x|s)|x)|~(~(x|s)|s);
+}
+
+int f2 (int x, int s)
+{
+ return ~(~(~x&s)&~(x&~s));
+}
+
+int f3 (int x, int s)
+{
+ return ~((x|~s)&(~x|s));
+}
+
+int f4 (int x, int s)
+{
+ return (~x|s)&(x|~s);
+}
--
Marc Glisse
manually checked
that the attribute has an effect.
2018-08-25 Marc Glisse
PR libstdc++/86822
* libsupc++/new (operator new(size_t, nothrow_t), operator
new[](size_t, nothrow_t), operator new(size_t, align_val_t, nothrow_t),
operator new[](size_t, align_val_t
c' markers of the bit_ior's
+ (bit_not (bit_xor @0 @1)))
+
+/* (~x | y) ^ (x | ~y) -> x ^ y */
+(simplify
+ (bit_xor (bit_ior:c (bit_not @0) @1) (bit_ior:c @0 (bit_not @1)))
+ (bit_xor @0 @1))
Likewise.
Wouldn't :s be ignored here, since there is a single instruction in the
output?
--
Marc Glisse
(cst), but that's not easy to formulate.
I was surprised not to see the impossible cases like ((a & b) < 0) & (a >=
0), but I don't mind their absence.
Other than those details, I think the patch looks good, thanks. (I am not
a reviewer)
--
Marc Glisse
x27;t look elsewhere.
* specialize relocation for some types (maybe deque?) where it can be
noexcept, possibly even trivial, whereas the move constructor cannot. If
we do that, we may want to specialize for pair/tuple/array as well, in
case one of the members is specialized.
2018-09-01 Marc
I forgot to attach the "diff -w" version of the patch, which may be a bit
more readable.
--
Marc GlisseIndex: include/bits/alloc_traits.h
===
--- include/bits/alloc_traits.h (revision 264027)
+++ include/bits/alloc_traits.h (working
On Sat, 1 Sep 2018, Marc Glisse wrote:
this patch passed bootstrap+regtest on powerpc64le-unknown-linux-gnu.
I realized afterwards that for a C++17-only feature, that's not testing
much... So I changed it to apply in C++14 and fixed a minor issue. There
is now a single regre
On Sun, 2 Sep 2018, Bernhard Reutner-Fischer wrote:
On 30 August 2018 22:20:06 CEST, Marc Glisse wrote:
Hello,
INTEGRALS_SIGN_PREC_MATCH: the name doesn't really match the semantics.
+#define INTEGRALS_SIGN_PREC_MATCH(A, B) \
+ TYPE_PRECISION (TREE_TYPE (A)) == TYPE_PREC
that guarantees we cannot get
(vec_merge (vec_concat (y) (z)) (vec_duplicate x) (const_int N))
?
I was wondering if it would be possible to merge the transformations for
concat and duplicate into a single one, but maybe it becomes too
unreadable.
--
Marc Glisse
in_bzero, which should be ok. The question
(independent from this patch) is then under what conditions bzero should
be detected as a builtin.
--
Marc Glisse
. */
(simplify
(min:c @0 (plus@2 @0 INTEGER_CST@1))
(if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0)))
(if (tree_int_cst_sgn (@1) > 0)
@0
@2)))
What is the type of all those SSA_NAMEs?
--
Marc Glisse
0);
if (!d) return false;
for instance.
100 was picked arbitrarily, I don't think it is worth having a param for
it, but we could certainly use a different value.
Bootstrap and testsuite on powerpc64le-unknown-linux-gnu.
2017-06-19 Marc Glisse
* gimple-match-head.c (depth_
On Mon, 19 Jun 2017, Richard Biener wrote:
On Sat, Jun 17, 2017 at 9:35 AM, Marc Glisse wrote:
Hello,
see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80887#c10 for the context.
FRE can go into an infinite recursion with some match.pd simplifications
(that have been temporarily reverted
It still shouldn't interfere with the patch by Robin Dapp which IIUC only
handles the case where the conversion is an extension.
2017-06-21 Marc Glisse
gcc/
* match.pd (nop_convert): New predicate.
((A +- CST1) +- CST2): Allow some NOP conversions.
gcc/testsuite/
Ping.
On Sat, 3 Jun 2017, Marc Glisse wrote:
Hello,
I don't think Richard's "sounds good" was meant as "ok to commit". Does an
x86 maintainer want to approve or criticize the patch?
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02009.html
On Fri, 26 May 20
ck in the
front-end could still work), it shouldn't be hard to implement some subset
of fold_addr_of_array_ref_difference in match.pd (it is recursive so a
complete move may be harder). But that would make your patch break even
more stuff :-(
--
Marc Glisse
strap + testsuite on powerpc64le-unknown-linux-gnu.
2017-06-22 Marc Glisse
gcc/
* tree.h (predeclared_type): New type.
(predeclared_types): Declare new array.
* tree.c (predeclared_types): New array.
(free_lang_data, build_common_tree_nodes): Use it.
gcc/c-f
y do those multiplications in an unsigned type. I experimented
with changing one such place in
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01641.html , there is
probably at least another one in the middle-end.
--
Marc Glisse
On Thu, 22 Jun 2017, Richard Biener wrote:
On Thu, Jun 22, 2017 at 10:46 AM, Marc Glisse wrote:
Hello,
I was asked to handle (const) fenv_t and fexcept_t the same way as FILE and
const tm. Since these have special handling in quite a few places, it seems
necessary to make their support a bit
On Thu, 22 Jun 2017, Richard Biener wrote:
On Thu, Jun 22, 2017 at 12:58 PM, Marc Glisse wrote:
On Thu, 22 Jun 2017, Richard Biener wrote:
On Thu, Jun 22, 2017 at 10:46 AM, Marc Glisse
wrote:
Hello,
I was asked to handle (const) fenv_t and fexcept_t the same way as FILE
and
const tm
+ testsuite on powerpc64le-unknown-linux-gnu.
2017-06-23 Marc Glisse
gcc/
* match.pd ((A+-B)+(C-A), (A+B)-(A-C)): New transformations.
gcc/testsuite/
* gcc.dg/tree-ssa/assoc-1.c: New file.
--
Marc GlisseIndex: gcc/match.pd
equivalent), you will notice that the above is
already available ;-)
--
Marc Glisse
d there is much we will be able to do with those, but at
least they are available now...
Trying to declare those functions with wrong prototypes now gives the
expected error.
Bootstrap + testsuite on powerpc64le-unknown-linux-gnu.
2017-06-23 Marc Glisse
* builtin-types.def (BT_
0(2), -1.0e+0(3)>
# prephitmp_6 = PHI
which phiopt3 can handle (quite late).
* With cond, this currently (?) only affects generic, so I am not sure it
will hit very often... But it will be there if someone later writes a
match.pd->phiopt generator ;-)
--
Marc Glisse
2017-06-26 Marc Glisse
gcc/
* match.pd ((X & ~Y) | (~X & Y)): Generalize to + and ^.
(x * C EQ/NE y * C): New transformation.
gcc/testsuite/
* gcc.dg/tree-ssa/addadd.c: Remove test duplicated in addadd-2.c.
* gcc.dg/tree-ssa/mulcmp-1.c: New file.
--
Mar
fine without this change, I only wanted to
raise the question in case someone knows.
--
Marc Glisse
+
+/* Transform copysign (-1.0, X) into copysign (1.0, X). */
+(simplify
+ (COPYSIGN real_minus_onep @0)
+ (COPYSIGN { build_one_cst (type); } @0))
(simplify
(COPYSIGN REAL_CST@0 @1)
(if (REAL_VALUE_NEGATIVE (TREE_REAL_CST (@0)))
(COPYSIGN (negate @0) @1)))
? Or does that create trouble with sNaN and only the 1.0 case is worth
the trouble?
--
Marc Glisse
On Mon, 26 Jun 2017, Richard Biener wrote:
I think the mults don't need :c as we should canonicalize the constant
to 2nd operand.
Oups, I copied the transformation above (which does need :c) and didn't
notice it was there. Good catch, thanks.
--
Marc Glisse
On Mon, 26 Jun 2017, Richard Biener wrote:
On Fri, Jun 23, 2017 at 3:12 PM, Marc Glisse wrote:
Hello,
here are a few simple transformations, mostly useful for types with
undefined overflow where we do not have reassoc.
I did not name the testcase reassoc-* to leave that namespace to the
pt. Then we get into
solving the same thing as IPA already does... And the standard does not
require implementations to be clever there. Still, it could have been nice
:-/
--
Marc Glisse
On Thu, 22 Jun 2017, Richard Biener wrote:
On Thu, 22 Jun 2017, Marc Glisse wrote:
On Thu, 22 Jun 2017, Richard Biener wrote:
If we consider pointers as unsigned, with a subtraction that has a signed
result with the constraint that overflow is undefined, we cannot model
that
optimally with
On Sun, 2 Jul 2017, Yuri Gribov wrote:
This is initial patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371 .
Thanks. I have had this unfinished, probably wrong patch on my hard drive
for 4 years, I doubt there is much you can extract from it, but just in
case...
--
Marc GlisseInde
On Sun, 2 Jul 2017, Yuri Gribov wrote:
On Sun, Jul 2, 2017 at 6:32 PM, Marc Glisse wrote:
On Sun, 2 Jul 2017, Yuri Gribov wrote:
This is initial patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371 .
Thanks. I have had this unfinished, probably wrong patch on my hard drive
for 4
that it is INTEGRAL_TYPE_P (or VECTOR_INTEGER_TYPE_P but then the result
would have to be VECTOR_FLOAT_TYPE_P, and since it gets compared to
REAL_CST... the test SCALAR_FLOAT_TYPE_P is actually redundant).
--
Marc Glisse
|/^) but not on the result of the bitwise
binary operation.
Sorry about that. If this canonicalization causes too much trouble, we
could revert it (it isn't important to me). Although it looks like you
managed to extend the store merging code nicely instead :-)
--
Marc Glisse
On Sun, 6 Aug 2017, Martin Sebor wrote:
+@item nonstring (@var{nonstring})
Hello,
what is the "(@var{nonstring})" for? This attribute does not seem to take
any argument...
--
Marc Glisse
On Sat, 28 Oct 2017, Marc Glisse wrote:
Hello,
first, if you are doing anything unusual with pointers (address spaces,
pointer/sizetype with weird sizes, instrumentation, etc), it would be great
if you could give this patch a try. It was bootstrapped and regtested on
powerpc64le-unknown-linux
sons, and the size gain is larger
than I expected, so I am posting the patch.
Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
2017-11-13 Marc Glisse
* include/bits/vector.tcc (vector::_M_realloc_insert): Cache old
values before the allocation.
--
Marc GlisseIndex: li
ch logic.
The 20040409 testcases were introduced to test an RTL transformation, so I
don't feel too bad adding -fwrapv to work around the undefined overflows
they exhibit.
Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
2017-11-13 Marc Glisse
gcc/
On Sat, 11 Nov 2017, Jakub Jelinek wrote:
On Sat, Nov 11, 2017 at 11:03:06PM +0100, Marc Glisse wrote:
--- gcc/tree-vrp.c (revision 254629)
+++ gcc/tree-vrp.c (working copy)
@@ -2086,20 +2086,38 @@ extract_range_from_binary_expr_1 (value_
else
On Sun, 12 Nov 2017, Martin Sebor wrote:
On 11/11/2017 03:03 PM, Marc Glisse wrote:
Hello,
with undefined overflow, just because we know nothing about one of the
arguments of an addition doesn't mean we can't say something about the
result. We could constrain more the cases where
Dijkstra
You could mention PR 54192 here.
* common.opt (ftrapping-math): Change default to 0.
* doc/invoke.texi (-ftrapping-math): Update documentation.
I am surprised that no testsuite change is needed.
--
Marc Glisse
sting passes without it.
* tree.def: New tree code POINTER_DIFF_EXPR.
The comment might mention that the value is the same for all pointer
types, not divided by the size of the pointed-to type.
Good idea, thanks.
--
Marc Glisse
ters, except in a few cases
where the patch simplifies more, but in a way that seems safe.
--
Marc Glisse
On Fri, 17 Nov 2017, Richard Biener wrote:
On Sat, Nov 11, 2017 at 12:44 AM, Marc Glisse wrote:
The exact undefined-behavior status should probably be clarified more.
First, I'd like to say that POINTER_DIFF_EXPR may only take 2 pointers into
the same "object" (like in C/C++),
hing to do
with this patch as long as the patch keeps the result of the subtraction
having the same type it does at present.
Well, that's good then. Is the C front-end part of the patch ok for you?
--
Marc Glisse
On Mon, 13 Nov 2017, Richard Biener wrote:
On Sat, Nov 11, 2017 at 11:03 PM, Marc Glisse wrote:
Hello,
with undefined overflow, just because we know nothing about one of the
arguments of an addition doesn't mean we can't say something about the
result. We could constrain more the c
Hello,
new version, regtested on powerpc64le-unknown-linux-gnu. The front-end
parts are up for review.
2017-10-28 Marc Glisse
gcc/c/
* c-fold.c (c_fully_fold_internal): Handle POINTER_DIFF_EXPR.
* c-typeck.c (pointer_diff): Use POINTER_DIFF_EXPR.
gcc/c-family/
* c
d [-INT_MAX, INT_MAX] for VR_VARYING | [1, 1]...
--
Marc Glisse
since the testcase in the PR
is rather on the undefined side of things, though ok for something
embedded)
--
Marc Glisse
On Wed, 22 Nov 2017, Marc Glisse wrote:
On Wed, 22 Nov 2017, Christophe Lyon wrote:
Since you committed this patch (r255021), my cross-builds of GCC for
aarch64-linux-gnu fail while building glibc:
/tmp/6857183_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/bin/aarch64-none-linux-gnu-gcc
Hello,
with POINTER_DIFF_EXPR, checking if the result is integral does not imply
that the arguments are as well, so this check needed a tweak.
Bootstrap+regtest on gcc112, pre-approved by Richard.
2017-11-22 Marc Glisse
PR tree-optimization/83104
gcc/
* vr-values.c
Hello,
I hadn't implemented this simplification because I think it is invalid
code, but apparently people do write it, so we might as well handle it
sensibly. This also happens to work around PR 83104 (already fixed).
bootstrap+regtest on powerpc64le-unknown-linux-gnu.
2017-11-22
On Wed, 22 Nov 2017, Jakub Jelinek wrote:
On Wed, Nov 22, 2017 at 06:34:08PM +0100, Marc Glisse wrote:
Hello,
I hadn't implemented this simplification because I think it is invalid code,
but apparently people do write it, so we might as well handle it sensibly.
This also happens to
On Sat, 18 Nov 2017, Jeff Law wrote:
* gimple-ssa-evrp-analyze.c: New file pulled from gimple-ssa-evrp.c.
With the move to C++, wasn't there a policy to name new files *.cc
instead of *.c?
--
Marc Glisse
might want to check with the committee if optimizing more calls is
ok.
--
Marc Glisse
On Thu, 23 Nov 2017, Richard Biener wrote:
On Wed, Nov 22, 2017 at 6:34 PM, Marc Glisse wrote:
Hello,
I hadn't implemented this simplification because I think it is invalid code,
but apparently people do write it, so we might as well handle it sensibly.
This also happens to work arou
:
‘IX86_BUILTIN__BDESC_SPECIAL_ARGS2_FIRST’ was not declared in this scope
BDESC_VERIFYS (IX86_BUILTIN__BDESC_SPECIAL_ARGS2_FIRST,
^
--
Marc Glisse
On Thu, 23 Nov 2017, Richard Biener wrote:
What about 0 - ptr? (ok, that's even more weird)
* match.pd (0-ptr): New transformation.
Regtested on gcc112.
--
Marc GlisseIndex: gcc/match.pd
===
--- gcc/match.pd (revision 2
301 - 400 of 1601 matches
Mail list logo
