https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #14 from Marc Glisse ---
Note that I don't think we ever got a proper bug report for GMP. Verified
instructions on how to reproduce the issue with just the latest version of GMP
(without having to download the sources of mpfr, mpc, is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70290
Marc Glisse changed:
What|Removed |Added
Summary|-mavx512vl breaks parsing |-mavx512vl breaks parsing
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
typedef int vec __attribute__((vector_size(32)));
vec f(vec x,vec y){return (x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70251
--- Comment #4 from Marc Glisse ---
(In reply to Ilya Enkovich from comment #2)
> Here is a responsible match.pd pattern:
>
> /* A + (B vcmp C ? 1 : 0) -> A - (B vcmp C), since vector comparisons
>return all-1 or all-0 results. */
Since we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70301
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70310
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
){
vec zero={};
vec one=zero+1;
vec c=x On Wed, 16 Mar 2016, glisse at gcc dot gnu.org wrote:
> > A + (B vcmp C ? 1 : 0) -> A - (B vcmp C ? -1 : 0)
> I think that would be an odd transform.
As far as I understand, since the bool vector changes, this is currently the
prop
: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
This comes from PR 68714 (comment 7), there are more details and suggestions
there.
typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #17 from Marc Glisse ---
(In reply to Andrew Roberts from comment #15)
> not entirely clear what you mean by reproducing the issue without
> downloading mpfr, mpc, isl etc. Do you mean the missing symbol in GMP or the
> issues with GM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #18 from Marc Glisse ---
Ah, I managed to reproduce. GMP has a nice "CFLAGS= -g -DNO_ASM" in its
Makefile, but gcc overrides it by calling make CFLAGS=-g. Not much we can do
from the GMP side (and ISL is innocent). Well, maybe the def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #19 from Marc Glisse ---
(In reply to Marc Glisse from comment #18)
> I think this issue was already described in another PR.
Ah, that was PR 69134 for MPFR.
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00127.html
ode
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
typedef double vecf __attribute__((vector_size(256)));
auto f(vecf x){
return x &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70318
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #20 from Marc Glisse ---
Does the latest GMP snapshot from https://gmplib.org/download/snapshot/ work
for you? I moved NO_ASM to config.h, so GCC's approach of overriding CFLAGS
should not break it anymore.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70317
--- Comment #3 from Marc Glisse ---
I'll get to it, but it may take a few days (hard to predict).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70317
--- Comment #5 from Marc Glisse ---
Yes, that looks good, thanks. Do double and long long always have the same size
(on platforms that support NaN)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70317
--- Comment #6 from Marc Glisse ---
(In reply to Marc Glisse from comment #5)
> Do double and long long always have the same size?
Ah, it doesn't matter since the result of <= is an opaque vector type and can
thus be implicitly cast even to a ve
#5)
> > > On Wed, 16 Mar 2016, glisse at gcc dot gnu.org wrote:
> > > > A + (B vcmp C ? 1 : 0) -> A - (B vcmp C ? -1 : 0)
> > > I think that would be an odd transform.
> >
> > As far as I understand, since the bool vector changes, this is curren
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42046
--- Comment #3 from Marc Glisse ---
(a?b|1:b&~1) could also be turned into (b&~1)+(a!=0) or (b|1)-(a==0) (or with ^
instead of +-, or | instead of +, etc) but it is quite possible that none of
those are a win.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70430
Marc Glisse changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
I have no idea how one would do such a transformation, and there is likely a
dup of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70438
--- Comment #1 from Marc Glisse ---
The result of a comparison is an "opaque" vector type, which can be converted
much more freely than a regular vector type, in case the guessed return type
doesn't exactly match the user's choice (it quickly dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70441
--- Comment #1 from Marc Glisse ---
C++ does not support dynamic allocation of over-aligned types (usually SIMD
vectors, but also __float128 on x86 for instance). C++17 will partially support
it (operator new), but still not fix the std::vector c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70444
--- Comment #2 from Marc Glisse ---
This code is likely broken, it looks like the last example in
https://gmplib.org/manual/C_002b_002b-Interface-Limitations.html
The temporary expression for v1+v2 dies before the next line, and you have a
dangl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23471
--- Comment #3 from Marc Glisse ---
The case a*a has been handled for a while, both in fold-const.c
(tree_binary_nonnegative_warnv_p) and in VRP. However, the case a*a*a*a*a*a is
not handled. In the .optimized dump at -O3, we still have:
b_3 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70509
--- Comment #3 from Marc Glisse ---
(In reply to Zdenek Sojka from comment #2)
> (In reply to Zdenek Sojka from comment #0)
> > First broken dump seems to be .forwprop, where is:
>
> .forwprop4 , that is. The problem might be that simplify_bitfi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70509
--- Comment #6 from Marc Glisse ---
(In reply to Zdenek Sojka from comment #5)
> It also fixes several wrong-code testcases that I failed to reduce to a
> reasonable size, thus were unreported.
Nice. While you are looking at those values that do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54700
--- Comment #1 from Marc Glisse ---
This was missing a simple testcase, but now we can write one (in C++):
typedef int vec __attribute__((vector_size(32)));
vec f(vec x){
return x<0?2:1;
}
vpxor %xmm1, %xmm1, %xmm1
vpcmpgtd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526
--- Comment #2 from Marc Glisse ---
(In reply to Markus Trippelsdorf from comment #1)
> -Wstrict-aliasing=2 warns:
>
> markus@x4 tmp % g++ -O2 -Wstrict-aliasing=2 test_fire.cpp
> test_fire.cpp: In instantiation of ‘const T* AlignedStorage2::addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70527
--- Comment #2 from Marc Glisse ---
(In reply to amker from comment #0)
> Seems "(long int) x * 12 - (long int)(x + 1) * 12" is missed in
> generic-simplify.
Interestingly, we manage just fine if 12 is replaced with a variable. The issue
seems t
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
In the example from http://stackoverflow.com/q/36414959/1918193 we fail to
vectorize f0
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
int f(int a,int b,int c,int d){
return (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70547
--- Comment #3 from Marc Glisse ---
In this case, the code was deliberately written this way, presumably to avoid
the branching in &&. Using & would be better (and that's what I am suggesting
we optimize it to), but * doesn't seem nonsensical to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70600
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70607
--- Comment #1 from Marc Glisse ---
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1137
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Looking at PR58483 (seems more relevant than PR62156), I tried this simple
testcase:
int a[]={1,2,3};
int f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70701
--- Comment #1 from Marc Glisse ---
Er, sorry, a "const" disappeared when I posted.
const int a[]={1,2,3};
int f(){
int*b=__builtin_malloc(12);
__builtin_memcpy(b,a,12);
return b[0];
}
this fails to optimize (without forwprop).
int a[]=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70708
--- Comment #1 from Marc Glisse ---
Looks complicated. _mm_set_sd(x) returns {x,0}, and I don't think the calling
convention guarantees anything about the unused part of SSE registers.
_mm_min_sd uses the high part of its first argument. So we ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70708
--- Comment #6 from Marc Glisse ---
(In reply to Petr from comment #3)
> Is there any workaround guys?
>
> I was looking for some built-in that would allow me just cast `double` to
> `__m128d` without going through `_mm_set_sd()`, but leaving th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483
--- Comment #9 from Marc Glisse ---
__builtin_memcpy (_30, &._82, 12);
_31 = MEM[(const int &)_30];
looks like something we should be able to optimize, and there is indeed code in
vn_reference_lookup_3 to that effect, but the code doesn't lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68211
--- Comment #2 from Marc Glisse ---
(In reply to H.J. Lu from comment #1)
> When the patch for PR 70708, I got
>
> vmovq %xmm0, %xmm0
> vsqrtsd {ru-sae}, %xmm0, %xmm0, %xmm0
> ret
Note that the goal of both PRs is to get rid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70708
Marc Glisse changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70708
--- Comment #14 from Marc Glisse ---
(In reply to H.J. Lu from comment #12)
> (In reply to Marc Glisse from comment #11)
> > As I told you in the other PR, movq is *NOT* what the PRs are asking for, it
>
> See the subject of this PR.
1) I know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70708
--- Comment #15 from Marc Glisse ---
(In reply to H.J. Lu from comment #13)
> (In reply to Marc Glisse from comment #11)
> > Since for MyMinV1 we generate no move at all, then that code should also be
> > valid for MyMinV2 (no issue with sNaN in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70721
--- Comment #2 from Marc Glisse ---
There were already a number of discussions on gcc-patches in 2012 (Oct, Nov,
Dec) with title "[i386] scalar ops that preserve the high part of a vector"
(see also PR54855). In particular, around this message, r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70723
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> There is no pass in GCC that would try to turn the runtime initialization
> into static init again (optimizing the runtime initializers and parsing
> them back to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70731
--- Comment #1 from Marc Glisse ---
That... seems dangerous to me. With floats, unsafe operations tend to change
the low bits. With integers, an overflow gets the high bits wrong. If you call
test(INT_MAX,0,1,0) for instance, the result would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70731
--- Comment #3 from Marc Glisse ---
(In reply to Josh Triplett from comment #2)
> That's a fair point. Perhaps it should go into a separate optimization
> option, then, though it still seems in the spirit of -Ofast. (If overflow
> is a concern,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70734
--- Comment #1 from Marc Glisse ---
gcc-6 produces
.cfi_startproc
addl%esi, %edi
movl%edi, (%rdx)
jo .L9
rep ret
.L9:
pushq %rax
.cfi_def_cfa_offset 16
callabort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70734
--- Comment #2 from Marc Glisse ---
(In reply to Marc Glisse from comment #1)
> movl%edi, (%rdx)
Looks like we fail to notice that the result of the addition is unused and keep
this dead store...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70734
--- Comment #7 from Marc Glisse ---
(In reply to Richard Biener from comment #3)
> It's not unused, it's stored to memory.
Of course, I read the testcase too quickly and thought *r was a throw-away
local variable... Sorry about that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #5 from Marc Glisse ---
It seems to me that the reason we don't already have div as a builtin is that
we need to know the layout of div_t.
In a header, you don't really need inline asm:
inline div_t div(int a, int b){ div_t q; q.quot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #8 from Marc Glisse ---
"The div, ldiv, and lldiv functions return a structure of type div_t, ldiv_t,
and lldiv_t, respectively, comprising both the quotient and the remainder. The
structures shall contain (in either order) the member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70767
--- Comment #1 from Marc Glisse ---
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559
It has status CD1, I don't remember if that means it applies retroactively or
not.
(by the way, the 4.8 branch is not maintained anymore)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70777
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Hello,
gcc.dg/gomp/loop-1.c recently gained a few xfails
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01417.html
Those happen because the C front-end folds i+=i to i*=2 before the OMP code has
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70841
--- Comment #1 from Marc Glisse ---
Related to PR55912.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70898
--- Comment #2 from Marc Glisse ---
I think you are supposed to use std::reference_wrapper as comparator if
you don't want to copy it around. We did talk about reducing the number of
copies (mostly in the context of sorting), but nobody has found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70898
--- Comment #4 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #3)
> This is being tracked as PR 51965
PR 51965 seems to be about extra copies of the values, while this one is more
about extra copies of compare objects (then there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68105
--- Comment #3 from Marc Glisse ---
(In reply to zboson from comment #0)
> In addition, the following equations are always true even without
> associative math.
>
> 2*a = a + a
> 3*a = a + a + a
> 4*a = a + a + a + a
> 5*a = a +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71029
Marc Glisse changed:
What|Removed |Added
Keywords||compile-time-hog
Status|UNCONF
P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
A very simple missed optimization, we optimize abs(x)<0 to false (in forwprop,
haven't found the exact place yet) but not abs(x) u&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71034
--- Comment #2 from Marc Glisse ---
(In reply to Andrew Pinski from comment #1)
> I think this is the optimizations that should be done:
> abs(x) < 0 -> x != x
for x=NaN, abs(x) is NaN, and NaN<0 is false. So the current simplification to
false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
--- Comment #7 from Marc Glisse ---
(In reply to Richard Biener from comment #6)
> C11 6.5.16/3 suggests that the LHS "operand" is evaluated in unspecified
> order.
It seems that C++ is moving towards specifying the order
http://www.open-std.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
--- Comment #9 from Marc Glisse ---
(In reply to rguent...@suse.de from comment #8)
> Not that I like this proposal at all (given it changes function arg
> evaluation order on x86_64).
Does it?
"the function is evaluated before all its argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71206
--- Comment #2 from Marc Glisse ---
With -O:
int f(int d, unsigned b) {
int i2 = b ^ 1;
int i4 = d ^ 1;
return i2 ^ i4;
}
An extra (convert ...) should do it I guess.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71206
--- Comment #4 from Marc Glisse ---
I am starting a bootstrap+regtest with:
/* (X ^ Y) ^ (X ^ Z) -> Y ^ Z */
(simplify
(bit_xor (convert1? (bit_xor:c @0 @1)) (convert2? (bit_xor:c @0 @2)))
(if (tree_nop_conversion_p (type, TREE_TYPE (@1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71206
--- Comment #6 from Marc Glisse ---
(In reply to Ilya Enkovich from comment #5)
> Could you please also check if it is a dup of PR71079?
Cf https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01598.html ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71079
--- Comment #2 from Marc Glisse ---
Author: glisse
Date: Fri May 20 09:44:50 2016
New Revision: 236504
URL: https://gcc.gnu.org/viewcvs?rev=236504&root=gcc&view=rev
Log:
PR71206: inconsistent types after match.pd transformation
2016-05-20 Marc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71206
--- Comment #7 from Marc Glisse ---
Author: glisse
Date: Fri May 20 09:44:50 2016
New Revision: 236504
URL: https://gcc.gnu.org/viewcvs?rev=236504&root=gcc&view=rev
Log:
PR71206: inconsistent types after match.pd transformation
2016-05-20 Marc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71079
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71206
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71218
--- Comment #1 from Marc Glisse ---
Can you be more specific? Do you mean people should have written:
T tab[8];
instead? What if 8 or sizeof(T) is large? If your "..." includes possible
writes to p, or if p escapes and "..." may throw, I guess th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71231
--- Comment #4 from Marc Glisse ---
(In reply to Andrew Pinski from comment #3)
> Maybe a missing :s or this could be just increasing register pressure.
:s would have no effect, you would need to do it manually
(simplify
(bit_and SSA_NAME@0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71231
--- Comment #12 from Marc Glisse ---
-fwrapv seems to fix it. As far as I can tell, the multiplication is done in 32
bits, VRP detects that the numbers are nonnegative, so zeroing the sign bit of
the result of the mult+add can be assumed to be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71231
--- Comment #15 from Marc Glisse ---
(In reply to rguent...@suse.de from comment #13)
> Anyone have a patch to rnflow that I can apply to the tester(s) to fix
> the issue?
It is easy enough to create a jsee_long of type integer(kind=8) and do th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71258
--- Comment #2 from Marc Glisse ---
inline void* operator new(std::size_t n){return __builtin_malloc(n);}
inline void operator delete(void*p, std::size_t){__builtin_free(p);}
And we get:
_5 = __builtin_malloc (16);
MEM[(struct model *)_5].D.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71289
--- Comment #1 from Marc Glisse ---
(In reply to Alexander Monakov from comment #0)
> I've tried to add the corresponding transform to match.pd, but it seems
> something else needs to be wired up as well, because it doesn't trigger.
> What am I m
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
#include
#include
struct A { A(A&&)=delete; };
static_assert(std::is_trivially_move_constructible>::value);
static_assert(!std::is_move_constructible>:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71289
--- Comment #3 from Marc Glisse ---
I think genmatch can handle calls to internal functions, the issue is with
guessing the return type. Maybe we could have a specific heuristic for these
functions in the case where the type is not explicitly spe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70923
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> We have vect_recog_mult_pattern that should have triggered here but that
> only tries replacement with LSHIFT_EXPR rather than also a simple plus
> for 2 * x.
I g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71408
--- Comment #1 from Marc Glisse ---
(Separately from the wrong code) some of the reads of c.f1 are represented as
BIT_FIELD_REF & 262143, which prevents us from optimizing it to a
constant (others that are represented as c.f1 work just fine) :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70923
--- Comment #6 from Marc Glisse ---
Created attachment 38646
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38646&action=edit
tentative patch
(you can ignore the expr.c bit, it is just because bootstrap is currently
broken on some platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71423
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71423
--- Comment #2 from Marc Glisse ---
match.pd has transformations like (~X & Y) -> X < Y for types of precision 1.
It looks like those are only valid if the type is unsigned, the comparison
should be reversed (Y < X) if the type is signed. I didn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70923
--- Comment #9 from Marc Glisse ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #7)
> It does: I just completed a sparc-sun-solaris2.12 bootstrap and the
> failures are gone. Unfortunately, the patch introduced new new
> regression:
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
This was posted by Peter Dimov in c++std-core-22683, and doesn't seem to have
found its way to our bugzilla.
#include
void f( std::initializer_list list )
{
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71414
--- Comment #2 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> The core loop is
>
> .L8:
> addq$1, %rdx
> vaddps (%r8), %ymm1, %ymm1
> addq$32, %r8
> cmpq%rdx, %rcx
> ja
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #16 from Marc Glisse ---
(In reply to rdapp from comment #15)
> Is there a simple method to access @inner when
> capturing
> (outer_op (convert (inner_op SSA_NAME@0 INTEGER_CST@1)) INTEGER_CST@2))
>^---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57745
--- Comment #2 from Marc Glisse ---
A()
A()
-
~C()
~B()
~B()
~A()
~A()
This is what I am getting from all recent versions of g++ (including 4.9.N) and
clang++ (as opposed to both ~A before in 4.8.N). That's not the exact
order asked i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57745
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71467
--- Comment #2 from Marc Glisse ---
DUP of PR55266? (there are probably other related PRs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71488
--- Comment #2 from Marc Glisse ---
Independently of the wrong code issue, we are generating pretty bad code on
Uros' testcase. It is full of operator delete(0) and operator new(0). The first
one we could drop, but the second one is forced by the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71526
--- Comment #2 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> this is the new /* MIN (X, C1) < C2 -> X < C2 || C1 < C2 */ pattern matching
> and using boolean_type (guessed by genmatch) for the result comparisons
> instead o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66313
--- Comment #11 from Marc Glisse ---
Does the patch still exist? Did it fail testing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71551
--- Comment #1 from Marc Glisse ---
Please include preprocessed source code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71558
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71563
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71563
--- Comment #3 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #2)
> That said, about the zero/non-zero bits, it is
> even more complicated in this case, because e.g. 1 / -1 has all bits set,
> the thing is just that it is then undef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795
--- Comment #12 from Marc Glisse ---
(In reply to Vincent Lefèvre from comment #11)
> On Debian, after path canonicalization, this is /usr/lib/bfd-plugins, but
> only packages should manage files under /usr/lib (unlike /usr/local, for
> instance)
1401 - 1500 of 2562 matches
Mail list logo
