https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176
Marc Glisse changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
Bug 58055 depends on bug 57176, which changed state.
Bug 57176 Summary: copy elision with function arguments passed by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #26 from Marc Glisse ---
(In reply to CVS Commits from comment #22)
> While the design of these builtins in clang is questionable,
> rather than being say
> unsigned __builtin_addc (unsigned, unsigned, bool, bool *)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783
--- Comment #12 from Marc Glisse ---
(In reply to Marc Glisse from comment #11)
> Since I had forgotten where it was, let me write here that it is git branch
> /users/glisse/fenv
Since it became impossible (hooks) to push to that branch a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190
--- Comment #6 from Marc Glisse ---
Indeed, this looks like a common issue (at least with the x86 backend): the
memory load is combined with the comparison before we try combining the
comparison with the blend, and this last combination is then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317
--- Comment #11 from Marc Glisse ---
(In reply to Richard Biener from comment #10)
> Should be fixed in GCC 13.
If I compile the original testcase with -O3, I get for test2:
_1 = this_6(D) + 16;
_2 = _6(D)->data1;
if (_1 != _2)
so we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107663
--- Comment #1 from Marc Glisse ---
Gcc often ignores the control flow for alias/escape analysis. v escapes at some
point, and that's enough to prevent gcc from noticing that nothing can have
written to v *before* the use. The same thing also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622
--- Comment #7 from Marc Glisse ---
(Wilhelm, when you post testcases, please post the full file including the
#include lines)
(In reply to Richard Biener from comment #5)
> Did you try -fstrict-enums?
IIUC, even if optimizations using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546
--- Comment #5 from Marc Glisse ---
typedef signed char v16qs __attribute__((vector_size(16)));
auto bar(v16qs x) { return x < 48; }
clang does expand it as 48 gt x. Gcc however does its usual change to x <= 47,
which it then tries to expand
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
In some C++ code I have, it would be convenient if the compiler, possibly with
the help of the standard library, could make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54346
--- Comment #6 from Marc Glisse ---
The log says that this breaks tree-ssa/forwprop-19.c, but I don't see any xfail
or anything. Does it only fail because gimple-simplify leaves some dead code
around, so you could update the test to scan the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107184
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #2)
> Confirmed - for array-bounds I added some "array-bound warning for %E"
> printing the SSA name/stmt in the dump file.
Sounds good, I'll try that next time the
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
One irritation with warnings like -Wuse-after-free and all the other
optimization-based warnings is how hard they are to track. Yes, it tells me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065
--- Comment #13 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #12)
> Doing it on the match.pd side doesn't look right, there could be many other
> optimizations that result in something similar.
$ grep -c non_lvalue match.pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065
--- Comment #11 from Marc Glisse ---
Did you try adding "non_lvalue" in match.pd? It looks less intrusive. Although
in the long term your approach seems better and the failures should be fixable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065
--- Comment #8 from Marc Glisse ---
(simplify
(bit_not (bit_not @0))
@0)
while in an other place we have
(simplify
(bit_and @0 integer_all_onesp)
(non_lvalue @0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
--- Comment #2 from Marc Glisse ---
A problematic optimization pointed in the discussion:
(simplify
(cmp @0 REAL_CST@1)
[...]
(if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1))
&& !tree_expr_signaling_nan_p (@1)
&&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783
--- Comment #11 from Marc Glisse ---
(In reply to Segher Boessenkool from comment #8)
> Thanks for the pointer, I'll find Marc's work.
Since I had forgotten where it was, let me write here that it is git branch
/users/glisse/fenv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106247
Marc Glisse changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Marc Glisse ---
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(from https://stackoverflow.com/q/73407636/1918193 )
#include
#include
#include
struct Foo {
auto join() const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #10 from Marc Glisse ---
(In reply to AK from comment #9)
> can't repro this with gcc 12.1 Seems like this is fixed?
No. As stated in other comments, it still reproduces with a longer string (or
with -D_GLIBCXX_USE_CXX11_ABI=0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105308
--- Comment #2 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #1)
> I'm unclear what the request is.
The list isn't super clear to me either, any sensible specialization of a
standard algorithm for a standard container. Even
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Hello,
with a balanced binary tree, as used for instance in std::set or std::map, it
is relatively easy to perform an operation in parallel on all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100929
--- Comment #6 from Marc Glisse ---
(blend is now lowered in gimple)
For the integer case, the mix of vector(int) and vector(char) obfuscates things
a bit, we have
__m256i if_else_int (__m256i x, __m256i y)
{
vector(32) char _4;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105062
--- Comment #2 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> But since not all of the std::max are recognized as
> MAX_EXPR but some only after loop if-conversion
Ah, I hadn't noticed. I tried replacing std::max with a
-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
The testcase is essentially the same as in PR105053, but here this is about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105053
--- Comment #8 from Marc Glisse ---
Thank you.
I originally noticed the problem with 11.2.0-18 (Debian), so I believe this
will be needed on that branch as well. 10.3.0 looked ok...
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
#include
#include
#include
#include
#include
int main(){
const long n = 1;
std::vector> vec;
vec.reserv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104675
--- Comment #6 from Marc Glisse ---
I am only learning now that bit ops don't exist for complex numbers :-/
I don't really see why not, but that's a different question. Thanks for fixing
this.
Looking to see if I could quickly find other
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(from a comment in PR 104389)
/* Maybe fold x * 0 to 0. The expressions aren't the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389
--- Comment #6 from Marc Glisse ---
Not this bug, but note that the comment and the code don't match in this
transformation: "a negative value" becomes !tree_expr_maybe_real_minus_zero_p
(@0) which is quite different. I am not sure the path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104361
--- Comment #2 from Marc Glisse ---
I looked at this paper for a different project a while ago, and it doesn't seem
like such a good match for C++ in general. While the basic idea looks simple
(use 2 counters, one for the thread that created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104239
--- Comment #2 from Marc Glisse ---
Thanks for fixing that bug, but don't you still have issues with
NO_WARN_X86_INTRINSICS if you rely on __has_include for immintrin.h?
-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
template
struct L: M {
using M::a;
void p() { this->template a<>; }
};
(accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104184
--- Comment #4 from Marc Glisse ---
https://geometrica.saclay.inria.fr/team/Marc.Glisse/tmp/mybug.cc.xz
(1.7M after compression still exceeds the limit)
With -Wall -Wextra
Internal compiler error: Error reporting routines re-entered.
0xec0348
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104184
--- Comment #3 from Marc Glisse ---
comment #1 actually reduces to
struct voider {
using type = void;
};
template struct rename : P {};
template using ignore = voider;
template typename ignore::type>::type g(T a) {}
void f() { g(1); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104184
--- Comment #2 from Marc Glisse ---
And the stack trace for comment #1
Internal compiler error: Error reporting routines re-entered.
0xff6b0d tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:16068
0xff5f6d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104184
--- Comment #1 from Marc Glisse ---
A different reduction from the same code. This one does not compile with clang
anymore. ICEs with -Wall -W, but not if I remove one of them.
using mp_false = struct mp_identity { using type = void; };
: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
This is reduced from valid code (I think) and it still compiles with "g++ -c
-w" or &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90433
--- Comment #3 from Marc Glisse ---
(In reply to Andrew Pinski from comment #2)
> The trunk we don't vectorize the code any more .
I thought it might be because we found a way to use memcpy instead, which would
have been good, but no, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51653
--- Comment #6 from Marc Glisse ---
(In reply to Andrew Pinski from comment #5)
> Is there anything more to do for this?
Yes. This PR is about having the library reorder the elements of a tuple to
minimize the size, and the current code does
++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Libstdc++ uses __SANITIZE_ADDRESS__ to detect if ASAN is enabled, but with
clang that should be __has_feature(address_sanitizer). This means that
_GLIBCXX_SANITIZE_STD_ALLOCATOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102760
--- Comment #3 from Marc Glisse ---
(In reply to Martin Liška from comment #2)
> Likely triggered with r7-821-gc7986356a1ca8e8e.
>From Andrew's comment, it looks like the bug is before that transformation,
since it receives a bit_and_expr of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53155
--- Comment #6 from Marc Glisse ---
(In reply to Andrew Pinski from comment #5)
> Hmm, Did something change in make?
It looks like make now splits -j from other flags in MFLAGS, -wkj becomes -kw
-j, so the old filters probably work now...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97868
--- Comment #6 from Marc Glisse ---
(In reply to pavlick from comment #5)
> Why is there false positive and no warning about the unsupported feature
> (atomic_thread_fence)?
You are probably using an old version of gcc. With a recent one, this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
Marc Glisse changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147
--- Comment #17 from Marc Glisse ---
(In reply to Hongtao.liu from comment #15)
> The issue can also be solved by folding __builtin_ia32_shufps to gimple
> VEC_PERM_EXPR,
Didn't you post a patch to do that last year? What happened to it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101795
--- Comment #1 from Marc Glisse ---
Hint: -fno-trapping-math lets it compile.
It should probably be accepted in a manifestly_const_eval context, although
some in the committee wanted to prevent the use of NaN (and sometimes even
infinity!) in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94356
--- Comment #6 from Marc Glisse ---
(In reply to Andrew Pinski from comment #5)
> Hmm, the following is worse:
That looks like a separate issue. We have fold_comparison for GENERIC, and
match.pd has related patterns for integers, or for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101659
--- Comment #1 from Marc Glisse ---
I already see some "__glibcxx_assert(this->_M_is_engaged());" in the code,
which IIUC should be enabled by _GLIBCXX_ASSERTIONS (and a fortiori by
_GLIBCXX_DEBUG). Did you actually try it?
++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(adapted from https://stackoverflow.com/q/68517921/1918193)
#ifdef WORK
#include
typedef std::array vec;
#else
typedef char vec __attribute__((vector_size(16)));
#endif
constexpr
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
bool f(char* p, long n)
{
bool r = true;
for(long i = 0; i < n; ++i)
r &= (p[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91099
Marc Glisse changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101611
--- Comment #7 from Marc Glisse ---
The same strategy to implement arithmetic shift in terms of logical shift works
not just for vector>>vector but also vector>>scalar and scalar>>scalar. But it
is probably not worth the trouble indeed,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101611
--- Comment #5 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #2)
> for arithmetic V[24]DImode >> V[24]DImode
> logical ((x >> y) ^ (0x8000ULL >> y)) - (0x8000ULL
> >> y)
> can be used.
I guess it would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56873
Marc Glisse changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
Stealing the example from PR 56873
#define SIZE 32
typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #25 from Marc Glisse ---
Note that this also affects dynamic linking with -Wl,--as-needed (which some
platforms use by default).
#include
int main(){
std::once_flag o;
std::call_once(o, [](){});
}
$ g++ b.cc -lpthread && ldd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49908
--- Comment #5 from Marc Glisse ---
(In reply to Andrew Pinski from comment #4)
> GCC builds now with the c++ which means this won't show up.
Just because g++ has an implicit -lm doesn't mean that any random 3rd-party C++
compiler does too.
(I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101501
--- Comment #2 from Marc Glisse ---
unsigned char a = 55;
int main() {
unsigned char c;
d:
c = a-- * 52;
if (c)
goto d;
__builtin_printf("%d\n", a);
}
outputs 40 at -O3 instead of 255, and already fails with gcc-8. Cunroll seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101063
--- Comment #1 from Marc Glisse ---
> Note 1: Under -Wall gcc generates warning:
> :5: warning: ignoring '#pragma STDC FENV_ACCESS' [-Wunknown-pragmas]
That seems like a huge hint, this is not implemented in gcc. You can find
several existing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54400
--- Comment #8 from Marc Glisse ---
(In reply to Richard Biener from comment #7)
> (note avoiding hadd in the reduc pattern was intended).
Indeed. Except with -Os, or if a processor with a fast hadd appears,
vectorising this doesn't bring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100929
--- Comment #4 from Marc Glisse ---
(In reply to Denis Yaroshevskiy from comment #3)
> Is what @Andrew Pinski copied enough?
I think so (it is missing the command line), although one example with an
integer type could also help in case floats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95405
--- Comment #5 from Marc Glisse ---
GIMPLE doesn't know about calling conventions, that's something that only
"appears" during expansion to RTL.
Still, I don't claim to understand what is going on here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95405
--- Comment #3 from Marc Glisse ---
For a self-contained version, see below. Notice how the extra constructor in
_Optional_payload_base changes the generated code, or storing directly a
_Optional_payload_base instead of _Optional_payload in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100929
Marc Glisse changed:
What|Removed |Added
Version|og10 (devel/omp/gcc-10) |11.1.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100929
--- Comment #1 from Marc Glisse ---
Please attach your testcases to the bug report. godbolt links are nice
complements, but not considered sufficient here.
We don't lower the comparison or the blend in GIMPLE (yet). I think Hongtao Liu
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100784
--- Comment #2 from Marc Glisse ---
Do we need to punt if there is no lhs?
(with optimization the call should be removed as pure)
I probably won't have time to try it for a while.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
Marc Glisse changed:
What|Removed |Added
Last reconfirmed||2021-05-26
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100746
--- Comment #1 from Marc Glisse ---
PR 80740 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
--- Comment #7 from Marc Glisse ---
It seems to help if we save the values before the allocation in vector.tcc,
although I cannot promise it won't pessimize something else... And that's just
a workaround, not a solution.
@@ -766,13 +766,16 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
--- Comment #6 from Marc Glisse ---
So, apart from the small missed PHI optimization, this is probably the common
issue that since operator new is replacable, we can't really assume that it
does not clobber anything, and that hurts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
--- Comment #5 from Marc Glisse ---
(In reply to Martin Sebor from comment #2)
> The IL looks like the warning is justified:
The memcpy call is dead code, we just fail to notice it.
>[local count: 230225493]:
> # prephitmp_42 = PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
Marc Glisse changed:
What|Removed |Added
Last reconfirmed||2021-05-02
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589
--- Comment #12 from Marc Glisse ---
(In reply to rguent...@suse.de from comment #11)
> For PR7
> I have prototyped a forwprop patch to try constant folding
> stmts with all-constant PHIs, thus in this case c$_M_value_2 > 0,
> when there's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589
--- Comment #8 from Marc Glisse ---
PR96480 would be my guess.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589
--- Comment #7 from Marc Glisse ---
Some key steps in the optimization:
PRE turns PHI<-1,0,1> > 0 into PHI<0,0,1>
reassoc then combines the operations (it didn't in gcc-10)
forwprop+phiopt cleans up (i>0)!=0?1:0 into just i>0.
Having to wait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100322
--- Comment #7 from Marc Glisse ---
PR94589 then.
: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(from https://stackoverflow.com/q/66100945/1918193)
double x[1000
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
(from https://stackoverflow.com/q/66023408/1918193 )
float f(float a){
unsigned ai;
__builtin_memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770
--- Comment #14 from Marc Glisse ---
(In reply to Orgad Shaneh from comment #13)
> The case described in comment 1 doesn't issue a warning with GCC 10.
It does for me with -Wall -O (you need at least some optimization). If there is
still a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98709
--- Comment #1 from Marc Glisse ---
At the end of gimple, we have
_6 = a_3(D) ^ b_4(D);
_1 = ~_6;
_2 = a_3(D) == b_4(D);
_7 = _1 & _2;
I guess we are missing a simplification of ~(a^b) to a==b for bool (similar to
~(a!=b) be we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607
--- Comment #9 from Marc Glisse ---
Since I doubt gdc handles rounding modes correctly for scalars, I think you can
ignore this issue in the implementation of the vector intrinsics for now (same
as we do in C and C++).
Note that gcc isn't alone
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
#include
std::atomic a;
double f(){ return a.load(std::memory_order_relaxed); }
is compiled by g++ to
movqa(%rip), %rax
movq%rax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98556
--- Comment #4 from Marc Glisse ---
The result of the subtraction is supposed to be an integer type, and is instead
an enum based on that underlying type? Maybe the verification code needs
tweaking to allow that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #8 from Marc Glisse ---
(In reply to Richard Biener from comment #4)
> We already handle IX86_BUILTIN_SHUFPD there but not IX86_BUILTIN_SHUFPS for
> some reason.
https://gcc.gnu.org/pipermail/gcc-patches/2019-May/521983.html
I was
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97085
--- Comment #6 from Marc Glisse ---
(In reply to Richard Biener from comment #5)
> (In reply to Marc Glisse from comment #4)
> > I would be happy with a revert of that patch, if the ARM backend gets fixed,
> > but indeed a missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97085
--- Comment #4 from Marc Glisse ---
I would be happy with a revert of that patch, if the ARM backend gets fixed,
but indeed a missed optimization should not cause an ICE.
(In reply to Richard Biener from comment #2)
> At least we're not at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96938
--- Comment #1 from Marc Glisse ---
With "char tmp" instead of "int tmp", we get the same code as the first
function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96918
--- Comment #5 from Marc Glisse ---
typedef unsigned short v8i16 __attribute__((vector_size(16)));
v8i16 bswap_epi16(v8i16 x)
{
return (x << 8) | (x >> 8);
}
We do recognize a rotate already in GENERIC
return x r<< 8;
But this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96912
--- Comment #2 from Marc Glisse ---
With consistent types, we recognize a VEC_COND_EXPR. With inconsistent types, I
guess we would need to reinterpret x and y as v16i8, and reinterpret the result
back to v2i64.
(please keep #include in your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96897
--- Comment #1 from Marc Glisse ---
We already transform to
return ~(-2 - x) | x;
so this is really asking for
~(-2 - x) --> x + 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #25 from Marc Glisse ---
(In reply to Feng Xue from comment #24)
> Another point: if B+-C can be folded to an existing gimple value, we might
> deduce B+-C does not overflow?
We can deduce that loading this value that represents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862
--- Comment #8 from Marc Glisse ---
Should we handle flag_trapping_math at the same time?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862
--- Comment #5 from Marc Glisse ---
"[Note: This document does not require an implementation to support the
FENV_ACCESS pragma; it is implementation-defined (15.8) whether the pragma
is supported. As a consequence, it is implementation-defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #14 from Marc Glisse ---
(In reply to Marc Glisse from comment #13)
> if (HONOR_SIGNED_ZEROS (mode))
> x2 = copysign (x2, x);
Hmm, I misread the comment, sorry. We already do that, for both floor and ceil.
But we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #13 from Marc Glisse ---
x-x does depend on the rounding mode (the transformation in match.pd gets it
wrong, by the way).
If the sign of 0 is the only issue, maybe we can test flag_rounding_math &&
flag_signed_zeros or the
1 - 100 of 2560 matches
Mail list logo
