https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87311
--- Comment #1 from Marc Glisse ---
/* -A - 1 -> ~A */
(simplify
(minus (convert? (negate @0)) integer_each_onep)
(if (!TYPE_OVERFLOW_TRAPS (type)
&& tree_nop_conversion_p (type, TREE_TYPE (@0)))
(bit_not (convert @0
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87317
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87315
--- Comment #1 from Marc Glisse ---
There could be 2 steps:
- replace the read with an undefined value (SSA_NAME with GIMPLE_NOP defining
statement). I vaguely remember someone was not enthusiastic about it, but I
don't remember why.
- fold a c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #20 from Marc Glisse ---
(In reply to Vincent Lefèvre from comment #18)
> OK, but then, this means that the first sentence of the
> -Wmaybe-uninitialized documentation is incorrect. That's probably the "there
> exists" that is problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87319
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87323
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87319
--- Comment #2 from Marc Glisse ---
*** Bug 87323 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87317
--- Comment #4 from Marc Glisse ---
> (match_operand:DI 1 "nonimmediate_operand" "m,*m,m")
Does it have to come from memory, can't it also come from a (sub)register?
int f(__m64 x){
__m128i y = _mm_movpi64_epi64(x); // or harder _mm_set1_epi6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71157
--- Comment #11 from Marc Glisse ---
Trunk doesn't show the warning (gcc-8 does).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87355
--- Comment #2 from Marc Glisse ---
For f, this is a classic case where gcc canonicalizes n>=100 as n>99, and thus
cannot as easily merge it with the other comparison n==100.
For g, n >= 103 || n == 100 || n == 101 || n == 102 is replaced in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57755
--- Comment #3 from Marc Glisse ---
(In reply to Eric Gallager from comment #2)
> (In reply to Marc Glisse from comment #1)
> > This patch seems to help for the testcases in this PR and passes the
> > testsuite (with one XPASS). I'll add some tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87319
--- Comment #4 from Marc Glisse ---
Author: glisse
Date: Tue Oct 2 14:55:39 2018
New Revision: 264790
URL: https://gcc.gnu.org/viewcvs?rev=264790&root=gcc&view=rev
Log:
No a*x+b*x factorization for signed vectors
2018-10-02 Marc Glisse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87258
--- Comment #2 from Marc Glisse ---
Author: glisse
Date: Tue Oct 2 14:59:25 2018
New Revision: 264791
URL: https://gcc.gnu.org/viewcvs?rev=264791&root=gcc&view=rev
Log:
vector _M_start and 0 offset
2018-10-02 Marc Glisse
PR libstdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87319
Marc Glisse changed:
What|Removed |Added
Keywords|wrong-code |
--- Comment #5 from Marc Glisse ---
Sorr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84334
--- Comment #1 from Marc Glisse ---
With -frounding-math, CCP produces things like:
_465 = 9.99974752427078783512115478515625e-7 +
4.99873689375817775726318359375e-6;
Guessing:
When we have cst1+cst2+cst3, the transformation gives cst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84361
Marc Glisse changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84436
--- Comment #4 from Marc Glisse ---
Note that this is good for identity, but we could also turn a map 0->3, 1->4,
5->8 into x->x+3, or generally any map (with an unreachable default case) into
a polynomial (or some other simple function), the cos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84470
--- Comment #1 from Marc Glisse ---
I can't see the difference between the 2 cases?
clang gives for both:
warning: comparison of array 'p->a' equal to a null pointer is always false
[-Wtautological-pointer-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
--- Comment #3 from Marc Glisse ---
Copying from
https://gcc.gnu.org/ml/gcc-help/2017-12/msg00031.html
"The way _mm_load_sd is currently implemented in gcc, yes, sanitizers are right
to complain. Intel could have named the thing _mm_loadu_sd if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
--- Comment #6 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Marc Glisse from comment #3)
> > Workaround: define a typedef for double with
> > __attribute__((__aligned__(1))), and use _mm_set_sd(*(newtype*)p), th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
--- Comment #7 from Marc Glisse ---
Unless vectors count as aggregates (more or less), in which case we can ignore
my previous comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84599
--- Comment #1 from Marc Glisse ---
Did you try -fsanitize=undefined before reporting?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #19 from Marc Glisse ---
(In reply to Aldy Hernandez from comment #16)
> It seems tree-ssa-reassoc.c avoids reassociating most non-bit expressions by
> design (because of signed overflows):
[...]
> So instead of whacking tree-ssa-reas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84604
--- Comment #1 from Marc Glisse ---
(In reply to Craig Schroeder from comment #0)
> this->~S();
> a=b+2;
What do you expect this to do? You destruct the object, then access its member
b...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66944
Marc Glisse changed:
What|Removed |Added
Last reconfirmed|2015-12-16 00:00:00 |2018-2-28
--- Comment #8 from Marc Glisse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84712
--- Comment #1 from Marc Glisse ---
We unroll quite late (cunroll) and there aren't any passes (like FRE) after
that to do the propagation. Adding #pragma GCC unroll 16 before the loop lets
it optimize.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84719
--- Comment #10 from Marc Glisse ---
(In reply to Richard Biener from comment #9)
> So with 2 bytes we get
Try 3 bytes (the worst case).
> Are you sure performance isn't dominated by the
> first init loop (both GCC and clang vectorize it).
Rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84744
--- Comment #5 from Marc Glisse ---
That's not how you use a different glibc. If you look at the include order
printed by -v, it has to remain in that order (libstdc++ before glibc, in
particular), whereas you are adding your glibc in front. Best
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84755
--- Comment #3 from Marc Glisse ---
gcc 4.6 and 4.8 branches are old and not supported anymore. Besides, trying
4.6.0 (with unidentified patches!) instead of 4.6.N with the largest possible
N is just asking for trouble (the problem may already b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84756
--- Comment #1 from Marc Glisse ---
We immediately narrow "return (Longer)a*b;" to "return a*b;" which makes it
hard to CSE later.
If you can, it would be better to write the code as:
Longer mul = (Longer)a*b;
... use mul twice ...
Not sure what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84824
--- Comment #4 from Marc Glisse ---
Probably related to PR59948, PR81000, etc. (I didn't look closely)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63734
--- Comment #8 from Marc Glisse ---
(In reply to Eric Gallager from comment #7)
> 5 branch is closed
You closed the PR, so does that mean you checked and it is fixed at least on
trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63734
--- Comment #10 from Marc Glisse ---
(In reply to Eric Gallager from comment #9)
> (In reply to Marc Glisse from comment #8)
> > (In reply to Eric Gallager from comment #7)
> > > 5 branch is closed
> >
> > You closed the PR, so does that mean yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85052
--- Comment #2 from Marc Glisse ---
Dup of PR61731.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048
--- Comment #4 from Marc Glisse ---
See PR77399.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85143
--- Comment #5 from Marc Glisse ---
The test becomes
_1 = n_15(D) <= i_46;
_2 = i_46 > 1336;
_3 = _1 | _2;
However, in match.pd, we only handle the AND case. The corresponding IOR
transformation should be handled similarly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85162
--- Comment #1 from Marc Glisse ---
If you believe this is incorrect, you should be able to extend the testcase
with an assert somewhere showing that the result is wrong.
For vectors, as documented, comparisons return a vector of 0 (false) and -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85236
--- Comment #2 from Marc Glisse ---
This is part of SVML, not a basic intrinsic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83860
--- Comment #6 from Marc Glisse ---
GMP's expression templates, which are based on libstdc++ valarray, have the
same issue. I tried using values in GMP (
https://gmplib.org/list-archives/gmp-bugs/2014-January/003319.html ). I never
committed it f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85236
--- Comment #5 from Marc Glisse ---
(In reply to bking from comment #4)
> I understand that is a part of SVML, but doesn't that mean using the Intel
> Compiler? Which means not using GCC. Is there not a plan to add it? Or is
> that the intent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63579
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713
Bug 55713 depends on bug 63579, which changed state.
Bug 63579 Summary: New attribute for empty member optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63579
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #3 from Marc Glisse ---
(In reply to M Welinder from comment #2)
> The destruction still stinks: the full destructor is inlined instead of
> the small-string-only version (i.e., a no-op). Evidently gcc cannot
> see that the string re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
Marc Glisse changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from Marc Glisse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #6 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #4)
> But the standard explicitly requires the
> allocator to be stupid, so I'm not sure what more libstdc++ can do here.
I think the standard specifies the fallback v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #7 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #5)
>static size_type
>_S_max_size(const _Tp_alloc_type& __a) _GLIBCXX_NOEXCEPT
>{
> - const size_t __diffmax =
> __gnu_cxx::__numeric_tra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #10 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #9)
> Do we want something like this as well? (and for malloc_allocator too)
I think so. Changing allocator_traits as LWG seems likely to agree won't help
much until
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #14 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #11)
> Why does it think we're calling it with max_size()?
_M_check_len contains a path (hopefully not taken, but gcc doesn't see that)
where it returns max_size(), a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #17 from Marc Glisse ---
(In reply to Martin Sebor from comment #16)
> The warning code considers just the argument to the call. It doesn't know
> (and in the constant case can't tell) where the argument came from. It
> would need t
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
The current overload of __uninitialized_copy_a that eventually dispatches to a
call to memmove is restricted to std::allocator. However, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #3 from Marc Glisse ---
Author: glisse
Date: Thu Oct 25 13:03:13 2018
New Revision: 265485
URL: https://gcc.gnu.org/viewcvs?rev=265485&root=gcc&view=rev
Log:
Relocation (= move+destroy)
2018-10-25 Marc Glisse
PR libstdc+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #5 from Marc Glisse ---
(In reply to Arthur O'Dwyer from comment #4)
> Have you seen my libc++ patch on the same topic as yours?
>
> https://quuxplusone.github.io/blog/2018/07/18/announcing-trivially-
> relocatable/
> https://github.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #6 from Marc Glisse ---
Re-reading P1144R0 (those are not necessarily comments on the paper, just what
comes to mind for gcc):
1) yes, an automatic detection mechanism would be nice, and an attribute makes
sense.
2) the conditionally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #8 from Marc Glisse ---
(In reply to Arthur O'Dwyer from comment #7)
> 2) the conditionally trivial stuff is not very convenient, it seems to
> involve a lot of code duplication. People regularly suggest attributes of the
> form [[t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #9 from Marc Glisse ---
I was looking into using relocation in std::swap. For a type like deque (if we
ignore the swap overload), using memcpy is really worth it. For a more simple
type like int, using memcpy loses type information, w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #11 from Marc Glisse ---
(In reply to Arthur O'Dwyer from comment #10)
> Here's the commit where I trivially-relocatable-ized `std::deque`. 34 lines
> added, 18 more lines changed. There's some duplication, but it's not
> literally "d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87787
--- Comment #1 from Marc Glisse ---
That would be my recent commit. We will probably need to add if(size!=0) in
front of the call to memmove...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87787
--- Comment #2 from Marc Glisse ---
(In reply to Marc Glisse from comment #1)
> That would be my recent commit. We will probably need to add if(size!=0) in
> front of the call to memmove...
That's what we already do in stl_algobase.h and fstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87822
--- Comment #1 from Marc Glisse ---
The easiest would be to make __pair_base a template so it is different for
different pairs and doesn't affect the layout when nesting pairs. But that
won't help for existing releases, especially when 6-branch j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87837
--- Comment #1 from Marc Glisse ---
The corresponding match.pd transformation already checks
TYPE_OVERFLOW_UNDEFINED, which apparently is not sufficient. That's
inconvenient, -ftrapv does change the value of that macro.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79191
--- Comment #5 from Marc Glisse ---
(In reply to Eric Gallager from comment #4)
> Where exactly in the compiler is this optimization supposed to be done and
Eric, that's part of the problem. The optimization already exists in VRP, but
it is defe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87954
--- Comment #4 from Marc Glisse ---
(In reply to Martin Liška from comment #3)
> Marc, are you planning to implement that in the future?
Not in the near future, no. It is all yours if you want it ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87976
--- Comment #4 from Marc Glisse ---
(In reply to Andrew Pinski from comment #1)
> apinski@xeond:~/src/toolchain-o7$ gcc t6.c -mavx -O2 -S -o - -march=native
> .file "t6.c"
> .text
> .p2align 4,,15
> .globl g
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44551
Marc Glisse changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58757
--- Comment #7 from Marc Glisse ---
If the testcase is still xfailed, I would say there is still something to be
fixed...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44551
--- Comment #19 from Marc Glisse ---
(In reply to Matthias Kretz from comment #18)
> FWIW, the issue is resolved on trunk. GCC8.2 still has the missed
> optimization: https://godbolt.org/z/hbgIIi
If I use exactly the testcase from the original d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371
--- Comment #10 from Marc Glisse ---
(In reply to Yury Gribov from comment #9)
> TBH I didn't implement all Josephs suggestions (particularly my patch does
> not try to optimize more under -ffast-math and friends)...
Your choice if you want to r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44551
--- Comment #21 from Marc Glisse ---
(In reply to Matthias Kretz from comment #20)
> The original issue I meant to report is fixed. There are many more missed
> optimizations in the original example, though.
ok, your choice if you prefer to clos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88118
Marc Glisse changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88118
--- Comment #5 from Marc Glisse ---
"An implementation is allowed to omit a call to a replaceable global allocation
function" (not any operator new) so I am not sure DECL_IS_OPERATOR_NEW is the
right test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #12 from Marc Glisse ---
Author: glisse
Date: Thu Nov 22 18:10:05 2018
New Revision: 266386
URL: https://gcc.gnu.org/viewcvs?rev=266386&root=gcc&view=rev
Log:
Improve relocation
2018-11-22 Marc Glisse
PR libstdc++/87106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88152
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173
--- Comment #3 from Marc Glisse ---
-fno-trapping-math is relevant. Gcc believes that comparing QNaN to something
requires setting a flag in fenv, which can only be done at runtime. I expect
that's wrong, or almost any operation on double would n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88174
--- Comment #1 from Marc Glisse ---
(In reply to emsr from comment #0)
> While updating libstdc++ for constexpr operators I came across this:
> __real__ _M_value += __z.real();
> is not constexpr even though
> __real__ _M_value = __z.real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #14 from Marc Glisse ---
(In reply to Arthur O'Dwyer from comment #13)
> Re https://gcc.gnu.org/viewcvs?rev=266386&root=gcc&view=rev — awesome, but
> I'm curious: Why `deque` before `vector`?
> I mean are you planning eventually to ad
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
double f(double a,double b){
return (a<0)?a:b;
}
typedef double vec __attribute__((vector_size(16)));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88189
Marc Glisse changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88189
--- Comment #4 from Marc Glisse ---
Thanks, that looks nice. I was wondering if it was better to define a scalar
version of the insn or to expand to the vector version + many subregs, but the
scalar version (your patch) matches what we already do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88241
--- Comment #1 from Marc Glisse ---
PR 54700?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54700
--- Comment #4 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #2)
> I'm not really sure if we can optimize v<0 for floating point v even with
> -fno-signed-zeros, isn't that option about allowing to optimize away x+0.0
> and similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54700
--- Comment #6 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Marc Glisse from comment #4)
> > __v4su
> > f (__v4su a, __v4su b, __v4su c)
> > {
> > return a > INT_MAX ? b : c;
> > }
>
> We should be folding th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234
--- Comment #6 from Marc Glisse ---
#define vec_add(a,b) ((a)+(b))
IIRC that only fails for __vector bool, but I think the ppc people didn't like
this approach.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88103
--- Comment #3 from Marc Glisse ---
Possibly unrelated, but PR 67795 is another example where ?: has the wrong
value category depending on where it is used (cast vs return).
>From my comment in https://gcc.gnu.org/ml/gcc-patches/2013-07/msg00234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88278
--- Comment #4 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #2)
> All these use something like:
> (insn 7 6 13 2 (set (reg:V8SI 87)
> (unspec:V8SI [
> (mem:V4SI (reg:DI 90) [0 *x_3(D)+0 S16 A128])
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88301
--- Comment #2 from Marc Glisse ---
In the EVRP dump, I see:
_2: unsigned int [0, 1]
_3: _Bool [0, 1]
[...]
_1 = REALPART_EXPR <_6>;
# RANGE [0, 1] NONZERO 1
_2 = IMAGPART_EXPR <_6>;
# RANGE [0, 0] NONZERO 0
_3 = (_BoolD.1896) _2;
N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88301
--- Comment #3 from Marc Glisse ---
(In reply to Marc Glisse from comment #2)
> Not sure where this [0, 0] range is coming from...
Well, I guess it is EVRP trying to encode __builtin_unreachable for _3!=0 in
the range information of _3, but not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53101
--- Comment #6 from Marc Glisse 2012-11-11 22:18:13
UTC ---
PR 48037 seems related (it was the scalar case).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55281
--- Comment #5 from Marc Glisse 2012-11-12 16:18:52
UTC ---
(In reply to comment #1)
[ Using ?: with a vector condition ]
> I was surprised only C++ handles this and not C BTW.
Sorry, I didn't have time to do a C version (harder than C+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55281
--- Comment #7 from Marc Glisse 2012-11-12 16:39:27
UTC ---
(In reply to comment #6)
> I'm just testing that, so I know it doesn't have side-effects.
I meant: instead of testing, so the optimization still occurs when there is a
side eff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55266
--- Comment #1 from Marc Glisse 2012-11-13 10:23:03
UTC ---
The first copy is PR 52436.
The second copy has a patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00900.html
The last copy would require turning:
gimple_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53024
Marc Glisse changed:
What|Removed |Added
Component|c |middle-end
Summary|Powe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55359
Bug #: 55359
Summary: [4.8 Regression] ICE in simplify_subreg accessing an
unaligned subvector
Classification: Unclassified
Product: gcc
Version: 4.8.0
Stat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53024
--- Comment #6 from Marc Glisse 2012-11-16 20:03:05
UTC ---
(In reply to comment #5)
> I don't think we can ever support vector size of non power 2 size.
I don't think we *will* ever support them (too much work, too little benefit),
but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53101
--- Comment #7 from Marc Glisse 2012-11-16 23:03:47
UTC ---
Created attachment 28713
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28713
Tweak on the patch of PR48037
This is a slight extension of Richard's patch for PR 48037. It
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55382
--- Comment #1 from Marc Glisse 2012-11-18 22:13:37
UTC ---
Seems related to PR 53017.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471
--- Comment #9 from Marc Glisse 2012-11-21 17:18:47
UTC ---
Jakub, your patch makes sense to me (or min0.is_zero() and min1.is_zero()). I
am ashamed I managed to get products with [0,n] (with n larger than MAX/2)
wrong. Good thing Kenneth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55425
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41233
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
1201 - 1300 of 2562 matches
Mail list logo
