https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
--- Comment #3 from Marc Glisse ---
Does profile feedback (so we have an idea on the loop count) make any
difference? It seems clear that for a loop that in practice just copies one
long, having to arrange the arguments, make a function call, tes
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(reduced from a user of boost/operators.hpp)
template class A;
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61338
--- Comment #3 from Marc Glisse ---
Possibly easier is the case of a reduction, where permutations are clearly
irrelevant.
int f(int*arr,int size){
int sum=0;
for(int i = 0; i < size; i++){
sum += arr[size-1-i];
}
return sum;
}
We s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94194
--- Comment #1 from Marc Glisse ---
Is there a convenient way for gcc to know the value of FE_DIVBYZERO, etc on the
target? Do we need to hardcode it? Can we rely on different libc on the same
processor to use the same value?
What happens if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94234
--- Comment #2 from Marc Glisse ---
The closest we have is
/* (A * C) +- (B * C) -> (A+-B) * C and (A * C) +- A -> A * (C+-1).
which does not handle conversions, although it should be possible to add them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94274
--- Comment #1 from Marc Glisse ---
Detecting common beginnings / endings in branches is something gcc does very
seldom. Even at -Os, for if(cond)f(b);else f(c); we need to wait until
rtl-optimizations to get a single call to f. (of course the re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293
--- Comment #1 from Marc Glisse ---
Adding
inline void* operator new(std::size_t n){return __builtin_malloc(n);}
inline void operator delete(void*p)noexcept{__builtin_free(p);}
inline void operator delete(void*p,std::size_t)noexcept{__builtin_fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94294
--- Comment #2 from Marc Glisse ---
(In reply to Eyal Rozenberg from comment #0)
> Note: I suppose it's theoretically possible that this bug only manifests
> because bug 94293 prevents the allocated space from being recognized as
> unused; but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293
--- Comment #4 from Marc Glisse ---
Or just
void f(){
int*p=new int[1];
*p=42;
delete[] p;
}
while it does optimize for
void f(){
int*p=new int;
*p=42;
delete p;
}
because the front-end gives us a clobber before operator delete.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295
--- Comment #1 from Marc Glisse ---
(In reply to Richard Smith from comment #0)
> The C++ language rules do not permit optimization (eg, deletion) of direct
> calls to 'operator new' and 'operator delete'.
I thought that was considered a bug?
Gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94294
--- Comment #4 from Marc Glisse ---
I don't believe there is a "new/delete" issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295
--- Comment #5 from Marc Glisse ---
(In reply to Richard Smith from comment #2)
> (In reply to Marc Glisse from comment #1)
> > (In reply to Richard Smith from comment #0)
> > > The C++ language rules do not permit optimization (eg, deletion) of
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(originally posted at
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-08/msg00276.html , I don't know
if we will do something about it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94314
--- Comment #5 from Marc Glisse ---
I don't think we need heavy machinery linking new and delete (and if we did I'd
be tempted to store it in some global table rather than in the nodes). The most
important case is the global replacable functions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94295
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94356
--- Comment #1 from Marc Glisse ---
That's because internally we use an unsigned type for offsets (including for
the multiplication). There have been tries to change that...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94356
--- Comment #3 from Marc Glisse ---
I tried https://gcc.gnu.org/pipermail/gcc-patches/2017-May/475037.html some
time ago. Having a different type for the multiplication and the offsetting
introduced a lot of NOPs and caused a few regressions (fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63706
Marc Glisse changed:
What|Removed |Added
Last reconfirmed||2020-03-29
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965
--- Comment #19 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #16)
> (In reply to Marc Glisse from comment #5)
> > (The split into push_heap and __push_heap is just so the first part can be
> > inlined without the second, right?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94412
Marc Glisse changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94141
--- Comment #1 from Marc Glisse ---
It looks like clang-10+ also generates an infinite loop on this code. Does the
standard really give priority to some implicit function over a user-defined one
that is an exact match?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94141
--- Comment #2 from Marc Glisse ---
Ah, maybe the friend function is not quite a template, so the generated swapped
function is not a template either, and thus it has priority over a template if
both are exact matches?
This is going to break a n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62080
Marc Glisse changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94314
--- Comment #10 from Marc Glisse ---
I am still getting -1 at -O2 for
#include
#include
int count = 0;
__attribute__((malloc,noinline))
void* operator new[](unsigned long sz){++count;return ::operator new(sz);}
void operator delete[](void* ptr
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
#include
int conv1(std::strong_ordering s){
if(s==std::strong_ordering::less) return -1;
if(s==std
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
g++-10 -std=gu++2a -O3
#include
bool k(int i){
auto c=i<=>0;
return c>0;
}
[local count: 1073741824]:
if (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94566
--- Comment #3 from Marc Glisse ---
I thought we had code to recognize a switch that represents a linear function,
I was hoping that it would kick in with your hoisting patch...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94798
--- Comment #1 from Marc Glisse ---
(In reply to Gabriel Ravier from comment #0)
> Comparison here : https://godbolt.org/z/LZ8dBy
In your future bug reports, could you please copy all relevant information
instead of (or in addition to) linking t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94801
--- Comment #1 from Marc Glisse ---
Gcc considers that clz might return 32 on some platforms, it does not currently
use target-specific information to restrict the range of clz output.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94801
--- Comment #2 from Marc Glisse ---
if(a==0)__builtin_unreachable();
lets gcc optimize the code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94811
Marc Glisse changed:
What|Removed |Added
Component|c++ |libstdc++
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94804
Marc Glisse changed:
What|Removed |Added
Keywords||ra
--- Comment #2 from Marc Glisse ---
Gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94804
--- Comment #4 from Marc Glisse ---
(In reply to Gabriel Ravier from comment #3)
> Having similar problems with useless movs is from the same non
> well-optimized register allocation on function boundaries ?
I don't know, but possibly not. I'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94908
--- Comment #1 from Marc Glisse ---
Even if we write __builtin_shuffle, the vector lowering pass turns it into the
same code (constructor of BIT_FIELD_REFs), which seems to indicate that the
target does not handle this pattern.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911
--- Comment #1 from Marc Glisse ---
gcc computes sizeof(a) as 4ul*(size_t)n, and unsigned types don't provide nice
overflow guarantees, so that complicates things.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911
--- Comment #3 from Marc Glisse ---
Since VLA is an extension for compatibility with C, it is strange that it
behaves differently (does one use the value of n at the time of the typedef and
the other at the time of the declaration?). This bug is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94905
--- Comment #1 from Marc Glisse ---
Several of us asked, and it was rejected. Your next step is to provide a
self-contained testcase (preprocessed sources?). You may also want to check if
it still warns in gcc-10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94919
--- Comment #1 from Marc Glisse ---
This seems related to another one you reported, in the category: i&-b == b?i:0
(for b∈{0,1}). The first form has the advantage of no branch, while the second
is less obfuscated and simplifies more naturally (li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94921
--- Comment #1 from Marc Glisse ---
x + y ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94930
--- Comment #1 from Marc Glisse ---
AFAIK -ftrapv doesn't work very well and is kind of abandoned, in favor of
-fsanitize=signed-integer-overflow (possibly with
-fsanitize-undefined-trap-on-error), which does generate the code you expect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94914
--- Comment #4 from Marc Glisse ---
I thought we might already simplify (u >> 32) != 0 to u >= cst (other possible
forms are u != (uint64_t)(uint32_t)u, u & cst != 0, etc, I am trying to think
which one looks most canonical).
I expect in interes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95001
--- Comment #3 from Marc Glisse ---
Simpler example:
[[noreturn]] void theend();
int f(int x){
if(x&7)theend();
return x&3;
}
(or replace "theend()" with "throw 42")
We shouldn't compute x&3, it is always 0 in the branch where it is compu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95044
--- Comment #1 from Marc Glisse ---
I think there is another very similar bug report.
# buf_1 = PHI <&stack_buf(2), buf_15(6)>
[...]
if (&stack_buf != buf_1)
in each branch, we thus know what buf_1 is, so we could replace it with buf_15
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95065
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91383
Marc Glisse changed:
What|Removed |Added
CC||gcc at linkmauve dot fr
--- Comment #6 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
--- Comment #1 from Marc Glisse ---
I am seeing the same thing on x86_64, happens during FRE1, so it looks like
tree-optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
--- Comment #2 from Marc Glisse ---
Or during CCP with the simpler
double f(){
double d=__builtin_inf();
return d/d;
}
and all the -frounding-math -ftrapping-math -fsignaling-nans don't seem to
help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
--- Comment #4 from Marc Glisse ---
(In reply to Jim Wilson from comment #3)
> The assumption here seems to be that if the user is
> dividing constants, then we don't need to worry about setting exception
> bits. If I write (4.0 / 3.0) for insta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95246
--- Comment #1 from Marc Glisse ---
On which version of LLVM did you see that? For me, gcc produces
movzbl %dil, %edi
movsbl %sil, %esi
cmpl%esi, %edi
setg%al
while clang skips the first 2 lines (but st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94141
Marc Glisse changed:
What|Removed |Added
Last reconfirmed||2020-05-21
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279
--- Comment #8 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #4)
> There is nothing wrong on addition of -1, whether signed or cast to
> size_t/uintptr_t, to a pointer,
Looking at the standard (I am not a pro at that), one could e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279
--- Comment #12 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #10)
> 1 + (size_t) -1 give 0
It wasn't obvious to me that the operation was supposed to happen in some C/C++
type (they don't say which one) or in a mathematical, infi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95351
--- Comment #2 from Marc Glisse ---
It might not be the issue, but merge_truthop_with_opposite_arm has a suspicious
HONOR_NANS (type) where type is bool: the result of the comparison instead of
one of the arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353
--- Comment #3 from Marc Glisse ---
Do you need fr_literal to have size at least 1 (say, when creating an object on
the stack), or can you use the official flexible array member (drop the 1, just
[] in the declaration)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95393
--- Comment #1 from Marc Glisse ---
It does optimize for me with -O2 or -O3. It could optimize earlier though, by
the end of gimple, we are still trying to return max(s,0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95423
--- Comment #3 from Marc Glisse ---
We manage it with -fwrapv. This should happen late when we don't care about
overflow anymore, or it needs to introduce casts to an unsigned type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95433
Marc Glisse changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435
Marc Glisse changed:
What|Removed |Added
Target||x86-*-*
--- Comment #3 from Marc Glisse -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95489
--- Comment #2 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> (bit_and (ne (bit_and x_3 y_4) 0) (ne x_3 0))
This could be simplified
> where I'd say we miss
>
> (bit_and (ne @0 integer_zerop) (ne @1 integer_zerop))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95384
--- Comment #2 from Marc Glisse ---
Or with less templates:
struct A {
A() = default;
union S {
constexpr S() noexcept : e() { }
struct {} e;
int i;
} s;
bool b = false;
};
struct B : A {
B() = default;
using A::A;
};
B f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #43 from Marc Glisse ---
(In reply to Niels Möller from comment #42)
> And what's the easiest way to run the the right compiler process (I guess
> that's cc1) under gdb?
gcc -c t.c -wrapper gdb,--args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95561
--- Comment #1 from Marc Glisse ---
Are you using -std=gnu++17 or -std=c++17 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95643
--- Comment #1 from Marc Glisse ---
After FRE1 we have
_2 = x_9(D) == 0;
if (_2 != 0)
so we assert things for _2 and not x_9, and we lose the __builtin_unreachable
information in CCP2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90436
--- Comment #2 from Marc Glisse ---
(writing down some notes)
Calling
size_type
_M_check_len_one(const char* __s) const
{
if (max_size() - size() < 1)
__throw_length_error(__N(__s));
const size_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90436
--- Comment #3 from Marc Glisse ---
// possibly assumes that ptrdiff_t and size_t have the same size
size_type
_M_check_len_one(const char* __str) const
{
ptrdiff_t __n = sizeof(_Tp);
ptrdiff_t __ms = max_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90436
--- Comment #4 from Marc Glisse ---
(side note not related to the redundant size checking)
It is surprising how, in the code from comment 2, adding v.reserve(1000) does
not help, it even slows the program down slightly here (yes, that's rather ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95801
--- Comment #1 from Marc Glisse ---
Except when dereferencing a pointer (?), gcc seldom uses an operation to derive
properties on the operands, it mostly derives properties on the result. That's
in large part because the information you are getti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95818
--- Comment #3 from Marc Glisse ---
Richard said "complete", that is the whole .i file, not just one random
function. If we cannot reproduce the issue by copying your code and compiling
it, we can't do anything about your report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95906
--- Comment #1 from Marc Glisse ---
I'd say generate a (vec_)cond_expr, not directly a max. That is, replace the
comparison with any truth_valued_p (hmm, that function probably stopped working
for vectors when all comparisons were wrapped in vec_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #12 from Marc Glisse ---
(In reply to Jeffrey A. Law from comment #10)
> __builtin_trap emits an actual trap into the instruction stream which halts
> the process immediately which is *much* better from a security standpoint
Regardle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95926
--- Comment #1 from Marc Glisse ---
It is different to gcc because in the first case, tmp is used twice, while in
the second case, each a&b is only used once, and gcc only transforms (a&b)^b to
b&~a if this is the only use of a&b. Yes, this heuri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95924
--- Comment #1 from Marc Glisse ---
* If I replace ~a with !a, we manage to do everything with type bool. With ~a,
we don't, we stick to int.
* We don't handle a?b:false the same as a&&b.
* Even for (a | !b) && (!(!a & b) && a) we don't complet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95929
--- Comment #1 from Marc Glisse ---
Here gcc does optimize the first f to (a != 0) ^ (b != 0). However, for the
second f, it does indeed generate something that looks like the first f before
optimization... The optimization for the first f is pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95923
--- Comment #1 from Marc Glisse ---
(With one variant I ended up with (a|b)&(a==b), which we don't optimize to a&b)
We don't optimize !(!a && !b) && !(!a && b) && !(a && !b) (we keep several
branches), but we do optimize if I manually replace en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95971
--- Comment #11 from Marc Glisse ---
while(!a.isZero());
that doesn't look like something you would find in real code. Are you waiting
for a different thread to modify a? Then you should use an atomic operation.
Are you waiting for the h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96009
--- Comment #2 from Marc Glisse ---
Note that we don't do the optimization if you replace double with long either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96065
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51571
Marc Glisse changed:
What|Removed |Added
CC||b7.10110111 at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96108
--- Comment #4 from Marc Glisse ---
During optimization, we often have branches with dead code that would exhibit
UB if it was ever executed. Cleaning up those branches as much as possible
helps reduce code size, show that some variables (in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96121
--- Comment #2 from Marc Glisse ---
gcc warns for this at the level of actual instructions, not user code. Since A
is empty, nothing uninitialized is getting copied.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96121
--- Comment #3 from Marc Glisse ---
And this translation unit doesn't actually generate any code at all, so the way
the warning is currently implemented has no chance of even looking at it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96121
--- Comment #5 from Marc Glisse ---
Yes, then we are back to the fact that it works for A=int but not for A a class
containing an int.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96088
--- Comment #3 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #2)
> Or use unordered_map, equal_to<>> which
> should perform better.
Good idea.
> We haven't implemented http://wg21.link/p0919r3 and http://wg21.link/p1690r1
> ye
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96369
Marc Glisse changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96327
--- Comment #5 from Marc Glisse ---
I don't think bug 3506 has been fixed (its status seems wrong to me). But don't
worry, there are several other duplicates that still have status NEW (bug 50677
for instance).
This is a sensible enhancement requ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96392
Marc Glisse changed:
What|Removed |Added
Last reconfirmed||2020-07-30
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95433
--- Comment #5 from Marc Glisse ---
Patch posted at
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551154.html for the
original testcase.
Note that solving univariate polynomial equations *in the integers* (the
rationals are not much hard
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
typedef long long veci __attribute__((vector_size(16)));
typedef double vecf __attribute__((vector_size(16)));
void f(veci v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96433
Marc Glisse changed:
What|Removed |Added
Component|c |tree-optimization
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70314
--- Comment #4 from Marc Glisse ---
We now generate for the original testcase
vpcmpd $1, %zmm3, %zmm2, %k1
vpcmpd $1, %zmm1, %zmm0, %k0{%k1}
vpmovm2d%k0, %zmm0
which looks great.
However, using | instead of &,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95906
--- Comment #3 from Marc Glisse ---
With the patch (which only affects vectors), f becomes (a>b)?a:b. It should be
easy to add the corresponding transform to MAX_EXPR in match.pd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670
Bug 88670 depends on bug 70314, which changed state.
Bug 70314 Summary: AVX512 not using kandw to combine comparison results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70314
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70314
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96513
--- Comment #1 from Marc Glisse ---
What you could do, even if it is private code, is reduce it
(https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction) until it is very small
and doesn't give away any IP, and then post it. Otherwise, there is no
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: arm-none-linux-gnueabihf
(see the discussion after
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551468
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542
--- Comment #2 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #1)
> In bar, this is optimized, because fold_binary_op_with_conditional_arg
> optimizes
> 255 >> (x ? 1 : 0) into x ? 127 : 255 and when multiplied by two in unsigned
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #1 from Marc Glisse ---
Does -fno-delete-null-pointer-checks help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48037
--- Comment #10 from Marc Glisse ---
We now generate just
sqrtpd %xmm0, %xmm0
for 2 and 4,
sqrtpd (%rdi), %xmm0
for 3, and
movupd (%rdi), %xmm0
sqrtpd %xmm0, %xmm0
for 1 (for alignment reasons I guess, the movu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96563
Marc Glisse changed:
What|Removed |Added
Last reconfirmed||2020-08-11
Ever confirmed|0
1 - 100 of 2562 matches
Mail list logo
